Compatibilità ocx in VisualStudio.NET 2003

lunedì 06 marzo 2006 - 14.22

lucius Profilo | Newbie

Ciao a tutti. Ho un problema: in un progetto sviluppato con VisualBasic 2003 .Net ho, nel form Main, un timer che fa la comunicazione con il PLC. Quando avviene l'evento tick, la prime istruzione è mettere Timer1.Enable a false, eseguo la comunicazione, e lo rimetto a true. Ho dovuto aggiungere l'ocx Winsock, e dopo l'inserimento mi capita che il TImer di comunicazione non venga Riabilitato, nel senso che non viene eseguita tutta la routine. Qualcuno mi sa dire se ha già avuto questo problema o come risolverlo? Grazie a tutti. Ciao

Brainkiller Profilo | Guru

>Qualcuno mi sa dire se ha già avuto questo problema o come risolverlo?

Ciao,
mai provato una soluzione di questo tipo. E' quasi una follia inserire un OCX dentro una Form .NET. Non puoi provare a rimpiazzare il controllo OCX con del tuo codice direttamente in .NET usando le classi del namespace System.NET (ossia Socket e/o TcpClient) ?

Che operazioni fai sul PLC con l'OCX ?

Ciao
David De Giacomi
Microsoft MVP
http://blogs.dotnethell.it/david/

lucius Profilo | Newbie

Con il PLC ho una comunicazione in Ethernet. Il PLC è un Siemens S7, protocollo SEND/RECEIVE. Purtroppo utilizzando le classi di VB.NET il PLC non risponde, o meglio mi dice che è connesso ma rifiuta ogni interrogazione. Comunque lo stesso problema l'ho avuto anche con MSComm.
Utilizzare le classi è un vero casino...

Brainkiller Profilo | Guru

>Con il PLC ho una comunicazione in Ethernet. Il PLC è un Siemens
>S7, protocollo SEND/RECEIVE. Purtroppo utilizzando le classi
>di VB.NET il PLC non risponde, o meglio mi dice che è connesso
>ma rifiuta ogni interrogazione. Comunque lo stesso problema l'ho
>avuto anche con MSComm.

Non so com'è il protocollo send/receive ma se sei collegato via Ethernet immagino con un RJ45 penso basterà un Socket, connect e poi gli mandi i comandi. Forse c'è qualche comando di inizializzazione da mandare prima di poter ricevere qualcosa. Un po' tipo l'HELO Degli SMTP Server.
Ciao

David De Giacomi
Microsoft MVP
http://blogs.dotnethell.it/david/

lucius Profilo | Newbie

Purtroppo non penso sia così. La connessione client è sempre aperta (il PLC è sempre in ricezione) e lui la connect la accetta. Il problema è che se invio qualche dato, lui non mi risponde e va in time out... Comunque il mio problema non è questo, ma il fatto che il programma in VB.NET perde alcuni eventi, tipo il Tick dei timer o alcuni click dei pulsanti. Se non posso usare gli ocx, non dovrebbe nemmeno farmeli installare o comunque usare... Al di la' del fatto che se prima ci mettevi cinque minuti a spedire dati in seriale o in ethernet, adesso ci perdi delle mezze giornate senza riuscirci....

Brainkiller Profilo | Guru

>Comunque il mio problema non è questo, ma
>il fatto che il programma in VB.NET perde alcuni eventi, tipo
>il Tick dei timer o alcuni click dei pulsanti.

>Se non posso usare
>gli ocx, non dovrebbe nemmeno farmeli installare o comunque usare...

Non è proprio così. .NET ti fa inserire gli OCX solo per mantenere una compatibilità con il passato. Qualunque guideline sull'uso di .NET consiglia di evitare gli OCX (proprio perchè appartenenti ad un'altra era ed un'altra piattaforma tecnologica COM/DCOM, codice unmanaged), e se proprio è necessario usarli, cercare di sostituirli con corrispondenti Custom Controls in codice managed .NET.

>Al di la' del fatto che se prima ci mettevi cinque minuti a spedire
>dati in seriale o in ethernet, adesso ci perdi delle mezze giornate
>senza riuscirci....

Sulla seriale posso darti ragione, perchè in VB.NET 2003 non c'è un controllo nativo per la gestione delle seriali, ma in .NET 2.0 e VS.NET 2005 finalmente c'è.

Riguardo la comunicazione Ethernet, io non so come funziona il PLC, immagino ci siano delle specifiche dove viene spiegato che protocollo usa e la serie di comandi che accetta o meno.

Se usi un protocollo diverso da quello che lui accetta o dei comandi a lui ignoti, è normale che il PLC non ti risponda.

I controlli OCX del vecchio VB6 sebbene fossero facili da usare non sono mai stati veramente di così grande utilità perchè nel momento in cui ti spostavi leggermente dalle 2 operazioncine in croce, eri fermo, di fatto sono stati eliminati e rimpiazzati da classi generiche ben più efficaci.

Ciao

David De Giacomi
Microsoft MVP
http://blogs.dotnethell.it/david/

lucius Profilo | Newbie

Su questo non discuto. Il fatto è che le prime macchine fatte con .NET usavo un driver di Siemens per comunicare con il PLC che era un ocx. Su dieci macchine fatte in questo modo, nove funzionano senza probkemi e una no (tra l'altro gemella di una che funziona).
Ho fatto un programmino ridotto all'osso per capire il problema. L'ocx richiede nei vari parametri un dato tipo Object che lui mi restituisce byref e io copio su una mia variabile di tipo Object. Dopo la copia mi trovo un array.
A volte durante la copia, il programma non torna al primo che l'ha chiamato (il timer di comunicazione), ma continua da un livello più basso (un timer che aggiorna le label). COsì facendo la mia comunicazione è morta. Se al posto di un dato object definisco io un array di single, ad esempio, il problema non sembra verificarsi. L'impressione è comunque che sembra che gli manchino le risorso per tornare al timer di comunicazione ma esegua l'evento tick del secondo.
Il tutto è perfettamente random

Brainkiller Profilo | Guru

>Su questo non discuto. Il fatto è che le prime macchine fatte
>con .NET usavo un driver di Siemens per comunicare con il PLC
>che era un ocx. Su dieci macchine fatte in questo modo, nove
>funzionano senza probkemi e una no (tra l'altro gemella di una
>che funziona).
>Ho fatto un programmino ridotto all'osso per capire il problema.
>L'ocx richiede nei vari parametri un dato tipo Object che lui
>mi restituisce byref e io copio su una mia variabile di tipo
>Object. Dopo la copia mi trovo un array.

Sembra che allora il tuo caso sia ben più complesso di quanto trasparisse nei primi post.

>Il tutto è perfettamente random

Wuaoh

In ogni caso ti confermo che non ho mai avuto problemi ad avere timer e OCX sulla stessa form. Probabilmente qui l'ulteriore componente PLC e la comunicazione con il client fanno qualcosa a noi sconosciuto.

ciao

David De Giacomi
Microsoft MVP
http://blogs.dotnethell.it/david/

lucius Profilo | Newbie

Tieni presente che man mano che ti scrivevo sono riuscito a localizzare il problema. Adesso ho tolto l'ocx di comunicazione verso il plc e il problema continua a farlo. Se metto un breackpoint nel timer di comunicazione (che simula solo la comunicazione con il PLC), lui funziona...Se dopo lo rimuovo continua a funzionare.

lucius Profilo | Newbie

Forse ho risolto: ho usato il Timer che si trova nella Toolbar "Componenti", che genera l'evento Elapsed. Adesso non mi da' più nessun problema. Lo lascio in Debug un paio di giorni prima di cantare vittoria, ma penso sia la soluzione. Anche se non so bene il perchè...

Brainkiller Profilo | Guru

>Forse ho risolto: ho usato il Timer che si trova nella Toolbar
>"Componenti", che genera l'evento Elapsed. Adesso non mi da'
>più nessun problema. Lo lascio in Debug un paio di giorni prima
>di cantare vittoria, ma penso sia la soluzione. Anche se non
>so bene il perchè...

Eh certo che si usa quello, che Timer utilizzavi tu ?

Ciao


David De Giacomi
Microsoft MVP
http://blogs.dotnethell.it/david/

lucius Profilo | Newbie

Usavo quello della classe Forms. Difatti ho sempre parlato di eventi Tick, mai Elapsed. Ciao
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2024
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5