| toma | vrijdag 27 februari 2009 @ 08:40 | |||||||
| Ik ben bezig een connectie op te zetten tussen mijn PC en een ander apparaat dmv VB.NET met een Winsock tool via Ethernet. Deze Winsock tool is een standaard tooltje van VB. Dit werkt helemaal geweldig, alleen kan ik geen data ontvangen van dat apparaat. Ik gebruik het commando GetData(). In dit commando moet ik drie parameters zetten: 'data', 'vbtype' en 'maxlen'. In de parameter 'data' wordt de data weggeschreven die afkomstig is van het andere apparaat. Het probleem is dat ik zeker weet dat er data verzonden wordt, maar het komt niet aan! Code:
| ||||||||
| TallMan | vrijdag 27 februari 2009 @ 11:36 | |||||||
| Je weet zeker dat je winsock control goed werkt ? Als ik op google zoek op AxOSWinsckControl.__Winsock_OnDataArrivalEvent (datatype van een van je params) kom ik alleen dit topic tegen terwijl ik dan stiekem toch zou verwachten iets meer tegen te komen. Kwa code lijkt het nogal op het ostrosoft winsock component, daarvoor staat sample code op de website, kun je die niet gebruiken om met je apparaat te communiceren ? Werkt het nog niet, waarom dan niet eens proberen met de system.net.sockets namespace ? Is de klassenaam van je winsock control ook Winsock ? het is meestal iets verhelderender om je objecten een andere naam te geven dan de klasses | ||||||||
| toma | vrijdag 27 februari 2009 @ 11:44 | |||||||
| Ja ik weet 100% zeker dat de communicatie goed werkt. Ik heb namelijk een industriële barcodescanner via ethernet aan m'n pc hangen. Deze kan ik aansturen dmv Winsock commando's. Alleen wanneer de barcode scanner gegevens terug stuurt krijg ik deze niet binnen. Terwijl hij wel een melding geeft dat er data is binnengekomen. Ik gebruik ook Wireshark om pakketten te onderscheppen. Ik zie ook dat de barcodescanner gegevens terug stuurt, maar deze data wordt niet in mijn variabel geschreven. Maar hoe werkt dat system.net.sockets namespace dan? | ||||||||
| TallMan | vrijdag 27 februari 2009 @ 12:30 | |||||||
| Heb je de help mee geinstalleerd ? Daar staat een hoop in. Ook een snelle google geeft je meerdere samples. Als je specifieke vragen hebt gooi ze maar hier neer, dan zie ik het wel weer in myAT. | ||||||||
| toma | vrijdag 27 februari 2009 @ 12:31 | |||||||
| toma | vrijdag 27 februari 2009 @ 16:32 | |||||||
| Ik ben nu bezig met de system.net.sockets. Er kan nu vlekkeloos een connectie opgezet worden en het zenden van data gaat ook goed. Maar het ontvangen gaat nog niet vlekkeloos. Als ik om Button3 klik moet hij data gaan ontvangen.
| ||||||||
| TallMan | vrijdag 27 februari 2009 @ 23:14 | |||||||
| Even voor de volledigheid, welke versie .NET gebruik je ? | ||||||||
| toma | vrijdag 27 februari 2009 @ 23:20 | |||||||
quote:Ik gebruik Visual Studio 2005 Express Edition met het .NET framework die je daarbij installeert. | ||||||||
| TallMan | zaterdag 28 februari 2009 @ 01:41 | |||||||
| Durf zo niet te zeggen waarom je hangt op die regel, de read is nonblocking en als er geen data is zou je meteen een 0 retour moeten krijgen. Ik heb zelf dmv de Socket klass gebruikt gemaakt van de namespace, op de socket klasse heb ik de Receive method gebruit. Maar iets zegt me dat als je read call blockt dat er toch iets anders niet lekker zit. Drivers van je netcard updaten misschien. Je zou met een chat serverChat server/client[/url] eens kunnen kijken of je uberhaupt iets door de sockets heenkrijgt. | ||||||||
| Tuvai.net | zondag 1 maart 2009 @ 19:42 | |||||||
| Als jij er 100% zeker van bent dat jou code werkt, dan zou ik de documentatie van het betreffende apparaat eens daar bij pakken. Veel hardware/apparaten waar softwarematig mee gecommuniceerd kan worden (althans waar ik mee gewerkt heb, voornamelijk modbus-pollers e.d.) hebben er een eigen beveiliging op na. Wat ik al heel vaak tegen ben gekomen bij dergelijke apparaatjes, is dat je eerst een code/commando moet sturen, alvorens je data geretourneerd kunt krijgen. | ||||||||
| toma | zondag 1 maart 2009 @ 21:06 | |||||||
quote:Dat klopt. Dat is bij deze barcodescanner ook het geval. Wanneer ik de juiste string met data verzend krijg ik als respons de gewenste data terug. Met behulp van Wireshark (een programmatje waarmee je data verkeer op je ethernet kaart monitort) zie ik dat de gewenste data ook verzonden wordt. Waarschijnlijk zit er dus iets fout in de VB code. Het nadeel is dat de documentatie bij deze barcodescanner zeer minimaal is, vooral wat betreft de communicatie via ethernet. | ||||||||
| TallMan | maandag 2 maart 2009 @ 00:19 | |||||||
| Ik mag aannemen dat de networkStream die je van je tcpClient afhaalt dezelfde networkstream is waarmee je je data verstuurt ? | ||||||||
| toma | maandag 2 maart 2009 @ 08:27 | |||||||
Om data te versturen gebruik ik deze code:
ik gebruik overigens niet de 2005 versie maar de 2008 express edition. | ||||||||
| TallMan | maandag 2 maart 2009 @ 08:43 | |||||||
Lekker handig overigens: MSDN over de Read method:quote:Dan zou ik toch denken non-blocking Kijk ik echter naar de NetworkStream en dan zie je quote:Toch maar even naar de DataAvailable property van je networkstream kijken, eventueel icm een timertje om em op je scherm te updaten. | ||||||||
| toma | maandag 2 maart 2009 @ 10:04 | |||||||
Het is inmiddels gelukt!
| ||||||||
| TallMan | maandag 2 maart 2009 @ 10:25 | |||||||
| Je weet dat je je myReadBuffer displayed voor je hem toevoegt aan je richedit waardoor je effectief 1x data achterloopt. Eerste keer schrijf je niets in je textbox want myReadBuffer is leeg Dan vul je je myReadBuffer Tweede keer schrijf je je data van de eerste leesactie in je textbox en dan lees je de 2de string in. | ||||||||
| toma | maandag 2 maart 2009 @ 11:24 | |||||||
| En hoe zou ik dat kunnen veranderen | ||||||||
| TallMan | maandag 2 maart 2009 @ 12:23 | |||||||
| Euh, misschien door te readen voordat je je data in je stringbuilder gaat flikkeren (regeltje 9 naar voor regeltje 8) Lijkt me toch vrij elementair | ||||||||
| toma | maandag 2 maart 2009 @ 13:57 | |||||||
quote:haha, dat had ik niet in de gaten. | ||||||||
| TallMan | maandag 2 maart 2009 @ 14:27 | |||||||
| Succes ermee verder | ||||||||
| toma | woensdag 11 maart 2009 @ 08:52 | |||||||
| Ik heb nog een vraag. Het blijkt dat wanneer ik vaak de connectie verbreek en opnieuw opstart er een error verschijnt. Dit probeer ik op te vangen dmv Structured Exception Handling. Maar helaas werkt dit niet. Er zijn 2 manieren om weer verbinding te krijgen met de barcodescanner en dat is door de barcodescanner handmatig te resetten (dmv een telnet commando te versturen of dmv een hardwarematige reset). Of door de VB applicatie af te sluiten en opnieuw op te starten, maar dit is niet de bedoeling. Ik gebruik voor het eerst Exception Handling, maar dit is de code die ik heb geschreven.
![]() Het blijkt dus dat er tijdens het connecten de volgende Exception afgehandeld dient te worden.
Hopelijk kan iemand me helpen. [ Bericht 0% gewijzigd door toma op 11-03-2009 13:11:34 ] | ||||||||
| TallMan | woensdag 11 maart 2009 @ 13:02 | |||||||
| je tcpclient, waar wordt die gezet, het probleem zal in de lifetime van dat object zitten dus alle News en Set Nothing van dat ding eens tracen. | ||||||||
| toma | woensdag 11 maart 2009 @ 13:18 | |||||||
quote:Sorry, maar ik begrijp niet wat je probeert te vertellen. Misschien dat je een voorbeeld kunt geven. | ||||||||
| Tuvai.net | woensdag 11 maart 2009 @ 13:24 | |||||||
quote:Hij bedoelt jouw tcpclient object. Waar wordt die aangemaakt en wat gebeurt daar in de levensduur van jouw applicatie mee? Doe je op 'het eind' van jouw applicatie wel netjes alles afsluiten wat 'open' staat? | ||||||||
| toma | woensdag 11 maart 2009 @ 13:32 | |||||||
quote:Ik declareer mijn tcpclient aan het begin van het programma als je dat soms bedoeld.
Moet ik deze tcpclient dan 'afsluiten' ? Ik snap het niet, maar dat komt ook omdat dit de eerste keer is dat ik met VB.NET werk. ;) | ||||||||
| Tuvai.net | woensdag 11 maart 2009 @ 14:24 | |||||||
quote:Een tcpclient object open je altijd met [tcpclient-objectnaam].connect() en dien je weer te sluiten met [tcpclient-objectnaam].close(). Dat doe jij in je stukje code ook, echter zie ik dat jouw Close() commando plaatsvindt in Function Disconnect, die op z'n beurt weer uitgevoerd word door Button2_Click(). Wordt Button2_Click() wel áltijd uitgevoerd? Wordt de tcpclient wel geclosed als je de applicatie bijvoorbeeld gewoon 'afsluit' middels het kruisje van je venster? | ||||||||
| toma | woensdag 11 maart 2009 @ 14:29 | |||||||
quote:Dat is niet zo zeer het probleem. Ik zet een verbinding op dmv Button1. Daarna krijg ik constant data toegestuurd. Wanneer ik op Button2 druk moet de verbinding afgesloten worden. Het probleem is dat wanneer ik weer op Button1 druk dat ie dan de volgende foutmelding geeft: ![]() | ||||||||
| toma | woensdag 11 maart 2009 @ 15:34 | |||||||
Ik heb de code aangepast.
Nu krijg ik de volgende foutmelding wanneer ik voor de tweede keer wil connecten. ![]() | ||||||||
| TallMan | woensdag 11 maart 2009 @ 15:37 | |||||||
Uit de help van de TcpClientquote:Dit verklaart nogal duidelijk waarom je een objectdisposedexception hebt kunnen vangen. Zeker erg onhandig omdat de connectie die er ligt naar je scanner open blijft waardoor een reconnect waarschijnlijk nogal moeilijk wordt (vaak willen dat soort apparaten maar 1 connectie accepteren) Je TcpClient heeft een Client propertie van het type socket. Deze heeft een disconnect. Mijn suggestie zou dan ook zijn om je Disconnect te veranderen van
in
Daarmee zeg je tegen de onderliggende socket dat de connectie afgebroken moet worden. Verder dispose je je object niet wat hergebruik nogal moeilijk maakt. Overigens nog een tip: ipv je exception.message en showen doe voor debuggen in ieder geval exception.ToString(), dan heb je een volledige stacktrace inclusief precies regelnummer waar je fout optrad. [ Bericht 62% gewijzigd door TallMan op 11-03-2009 15:47:01 ] | ||||||||
| toma | donderdag 12 maart 2009 @ 10:05 | |||||||
| Bedankt voor de reactie, maar helaas werkt het nog niet. Wanneer ik
of
gebruik dan krijg ik deze error: ![]() Ik gebruik onderstaande code om te connecten:
Wanneer ik deze verander in:
Dan krijg ik geen error. Maar dan maakt hij ook geen verbinding meer. Het vreemde is dat wanneer ik de VB applicatie afsluit en opnieuw opstart dat ik dan wél weer verbinding kan maken. | ||||||||
| TallMan | donderdag 12 maart 2009 @ 10:58 | |||||||
| BeginConnect en zijn maatje EndConnect zijn zware overkill voor je, die maken het alleen moeilijker ipv je probleem op te lossen Ik zou denk ik in de Connectie methode de volgende wijziging doen
naar
| ||||||||
| toma | donderdag 12 maart 2009 @ 12:07 | |||||||
| Bedankt dat was het Maar waarom moet ik die Client opnieuw declareren? Omdat het object gedisposed is? | ||||||||
| Tuvai.net | donderdag 12 maart 2009 @ 12:38 | |||||||
quote:Zodra je objecten disposed, dan gooi je ze 'weg' zoals de handeling al impliceert. Het hele object wordt weggegooid en ook het geheugen dat het betreffende object in beslag nam komt weer vrij. Dit is heel belangrijk in daadwerkelijke applicaties. In bijvoorbeeld webapplicaties hoef je daar veel minder rekening te houden omdat een webpagina op de server á la minute geparsed en na het weergeven/presenteren aan de gebruiker meteen vernietigd wordt. Connecties naar apparatuur of databases werken dan weer anders. Je legt een verbinding met iets, en je webpagina/applicatie laat deze verbinding dus voor een tijdje open staan (idle) als je de verbinding niet sluit. Veel apparaten en databases vinden het op z'n beurt weer niet zo leuk om te veel openstaande verbindingen te hebben en hebben daar ook vaak een limiet aan. | ||||||||
| TallMan | donderdag 12 maart 2009 @ 12:48 | |||||||
| Wat Tuvai zegt. En schijnbaar is de TcpClient een beetje onhandig om hergebruikt te krijgen, zodra zoiets teveel moeite kost is het al snel makkelijker om een nieuwe te pakken. Het.NET framework is wel weer zo aardig dat als jij dingen niet meer gebruikt hij het voor je opruimt. Neemt niet weg dat ik toch aanraad om netjes met je objecten om te springen, sockets/db connecties netjes disconnecten etc. In de bovenstaande (werkende optie) maak je een nieuwe TcpClient aan die volledig vers in het geheugen komt te zitten. Het framework herkent dat jij nergens meer een verwijzing naar de oude TcpClient heeft en die ruimt het voor je op. Niet alle talen zijn zo aaridg voor je, mocht je met C/C++ aan de slag moeten dan moet je zelf het opruimen regelen. | ||||||||
| Catbert | donderdag 12 maart 2009 @ 14:12 | |||||||
quote:FYI: Dat is in het geval van Asp.net en Java absoluut niet zo. Je hebt daar gewoon een application scope. Het is altijd zaak om dit soort objecten netjes op te ruimen, er is geen garantie dat de GC ze kan verwijderen, daarom hebben ze een dispose methode. |