Communication Error 5: Acesso negado

[Turbo Drive]

Bom dia

Estou precisando trabalhar com o AcbrECF em minha aplicação.

Estou tendo problemas de comunicação, inicialmente com a Daruma, pois é o ECF que disponho no momento.

Ao tentar me comunicar com minha aplicação, aparece o seguinte erro:

Communication Error 5: Acesso Negado

Pesquisei aqui no fórum, mas o que foi informado, não foi suficiente para me ajudar.

Sempre que inicio a minha aplicação, antes de chamar as funções ou ativar o componente, o ECF dá um beep.

O exemplo que vem nos fontes, comunica sem problemas.

A minha aplicação ainda possui as função das dlls dos fabricantes no código fonte. Seria esse o problema ?

Existe alguma forma de coexistir no código fonte, as funções das dlls e o componente AcbrECF ?

O AcbrEcf, usa as dlls ou faz comunicação direta ?

Teria como me mandar um exemplo de como configurar o componente ?

Desde já agradeço a atenção.

[Juliomar Marchetti]

Isso ocorre com o ECFTeste?

compile ele e teste ! se sim veja as configurações de porta se condiz!

[Turbo Drive]

O exemplo que vem nos fontes, comunica sem problemas.

A minha aplicação ainda possui as função das dlls dos fabricantes no código fonte. Seria esse o problema ?

Existe alguma forma de coexistir no código fonte, as funções das dlls e o componente AcbrECF ?

O AcbrEcf, usa as dlls ou faz comunicação direta ?

Teria como me mandar um exemplo de como configurar o componente ?

Desde já agradeço a atenção.

[Juliomar Marchetti]

Veja no objeto Device dentro do ACBrECF !

com certeza é algo com a configuração da porta, seja velocidade, paridade e etc!

tente comparar antes de ativar o ACBrECF!

[Turbo Drive]

Deixei os mesmos valores do exemplo, mas o erro ainda persiste. Mas dessa vez, não houve o beep, nem da minha aplicação, nem do programa exemplo.

Já o programa exemplo, comunica sem problemas, mesmo estando em um diretório sem nenhuma dll do fabricante.

A minha aplicação ainda tem no código fonte com as chamadas das funções da dll. Tem algum problema ?

O componente ele utiliza as dlls ou faz comunicação direta ?

 

[Turbo Drive]

O componente em minha aplicação e no exemplo, estão iguais. Segue o trecho dos logs:

Gerado pelo programa exemplo.

ATIVAR - 28/11/15 10:52:49:953 - Modelo: Daruma - Porta: COM6 - TimeOut: 3
         Device: BAUD=9600 DATA=8 PARITY=N STOP=1 HANDSHAKE=RTS/CTS HARDFLOW MAXBANDWIDTH=0
--------------------------------------------------------------------------------

Gerado pela minha aplicação

ATIVAR - 28/11/15 10:54:38:891 - Modelo: Daruma - Porta: COM6 - TimeOut: 3
         Device: BAUD=9600 DATA=8 PARITY=N STOP=1 HANDSHAKE=RTS/CTS HARDFLOW MAXBANDWIDTH=0

 

Como uso as dlls dos fabricantes, usei as dicas desse site para desabilitar a DarumaFrameWork.dll:

http://www.desenvolvedoresdaruma.com.br/dde/htmls/dde036_2013-nao-ocupar-serial.html

Quando ativo o componente no exemplo, a impressora não faz o beep. Mas ao iniciar a minha aplicação, o ECF faz o beep.

Seria a DarumaFrameWork.dll que ainda esteja ocupando a porta ?

Alguém teria alguma idéia, sobre o que poderia estar ocorrendo ? 

[Daniel Simoes]

A mensagem é bem clara... a porta não pode ser acessada pelo ACBrECF, pois está em uso por outra aplicação..

[Alessandro Cruz]

Daniel,

Já possuo uma aplicação que se conecta a impressora Daruma em um cliente normalmente. No momento estou desenvolvendo outra e estou utilizando os mesmos códigos. Aqui em minha máquina utilizo a impressora virtual da Sweda e tudo flui normalmente, porém quando vou testar no cliente ao ativar a impressora dá o erro de acesso negado. Entendo o que você diz quando fala que a mensagem é clara e que a porta não pode ser acessada. O problema é que não há nenhuma aplicação utilizando. Se eu reinicio a máquina com a impressora desligada, abro a minha aplicação e ligo a impressora dá o erro. Se fecho minha aplicação e abro o ECFTeste consigo conectar normalmente.

Para piorar minha situação descobri que, se abrir o ECFTeste e ativar a impressora, e em seguida abrir minha aplicação e tento ativar, recebo o erro de retorno, mas nesse caso de forma correta porque o ECFTeste está conectado a impressora, mas se eu fechar o ECFTeste e imediatamente após clico em ativar em minha aplicação ela conecta normalmente sem problemas.

Não sei mais o que fazer para resolver, será que você teria uma ideia do que pode estar ocorrendo???

[Daniel Simoes]

Não há nada que possa ser feito do lado do ACBrECF... não é ele que está prendendo a porta...

Você deve entrar em contato com o suporte do fabricante...

[Alessandro Cruz]

11 minutos atrás, Daniel Simoes disse:

Não há nada que possa ser feito do lado do ACBrECF... não é ele que está prendendo a porta...

Você deve entrar em contato com o suporte do fabricante...

Não estou dizendo que o problema é o ACBrECF, até porque como falei a outra aplicação desenvolvida por mim funciona normalmente, o problema está com essa aplicação nova. Inclusive após fechar a aplicação conectada com a que dá o erro aberta e em seguida clico em ativar, a ativação ocorre normalmente e consigo utilizar as funçoes da impressora.

Estava pensando ser algo na minha aplicação nova que tenha esquecido de configurar.

De qualquer forma obrigado pela atenção.

[Alessandro Cruz]

Em 28/11/2015 at 12:06, Turbo Drive disse:

O componente em minha aplicação e no exemplo, estão iguais. Segue o trecho dos logs:

Gerado pelo programa exemplo.

ATIVAR - 28/11/15 10:52:49:953 - Modelo: Daruma - Porta: COM6 - TimeOut: 3
         Device: BAUD=9600 DATA=8 PARITY=N STOP=1 HANDSHAKE=RTS/CTS HARDFLOW MAXBANDWIDTH=0
--------------------------------------------------------------------------------

Gerado pela minha aplicação

ATIVAR - 28/11/15 10:54:38:891 - Modelo: Daruma - Porta: COM6 - TimeOut: 3
         Device: BAUD=9600 DATA=8 PARITY=N STOP=1 HANDSHAKE=RTS/CTS HARDFLOW MAXBANDWIDTH=0

 

Como uso as dlls dos fabricantes, usei as dicas desse site para desabilitar a DarumaFrameWork.dll:

http://www.desenvolvedoresdaruma.com.br/dde/htmls/dde036_2013-nao-ocupar-serial.html

Quando ativo o componente no exemplo, a impressora não faz o beep. Mas ao iniciar a minha aplicação, o ECF faz o beep.

Seria a DarumaFrameWork.dll que ainda esteja ocupando a porta ?

Alguém teria alguma idéia, sobre o que poderia estar ocorrendo ? 

Confirmado, o problema da aplicação era a declaração da dll do fabricante.

Como estou  implementando o ACBRECF em substituição a utilização da DLL este problema ocorreu.

Como utilizo uma impressora virtual da Sweda em minha máquina não percebia o problema.