Bad Packets ModBusTCP

[Valarauca]

I'm having an issue with packets being gargled in modbus TCP.

Here is a screenshot of the packet in wireshark

And here is the packet in labview.

.

The two are very different.

Also on the packet, he header is allocated 7 bytes of space (2 for Transaction Identifier, 2 for Protocal, 2 for Length, 1 for Unit ID). And I'll read 7 packets incoming, but it appears shifted, aka 6 not 3, and the entire packet appears wrong.

What confuses me is that I'm that function code and the rest of packets appears correctly in wireshark, and labview is reading it correctly when the binary data isn't that same.

Help, please

Cody.

 P.S.: All my code can be found at https://github.com/valarauca/G-MODbus-TCP-MBA-lib

[Valarauca]

Bumping to see if anyone else can assist.

[Esteban.R]

Hi Valarauca

I downloaded your library but there are many VIs and subVIs could you tell me which VIs should I open in order to try to reproduce the problem?

Regards

Esteban R.

[Valarauca]

Go into dependancy and deps.

Main.vi

It will contain all the primary code, and its execution.

The problem exists in

Main Vi > MB Ethernet Slave Deamon - Single Port - Multiple Connections.vi > MB Ethernet Slave Communication.vi > MB Ethernet Recieve.vi

On getting a packet, it doesn't match the packet in wireshark. (You'll need to create a global so you can view the packet, I believe this is already set up in the main.vi frontpanel)

[Valarauca]

Some additional information to help you troubleshoot.

When you only have a single VI requesting a single Unit ID from the host (main.vi) the packets come into the system 'clean'. I see no difference between wireshark and NI's TCP functions.

But when I request from multiple Unit ID's in the same function, then the packets get slightly gargled. I've tried 'slowing down' the execution by a second (one second between packets) to allow for the OS to flush it's TCP buffer (thinking the OS might just join those TCP packets together or something, I've see stranger things). 

Attached is the VI I'm using to poll from the main.vi server (it can also be found on the git repo).

[Valarauca]

Another update.

These 'bad packets' apperently don't require a TCP connection. Just running the ethernet daemon causes them to be recieved at ~60 per second. Which means I know have to filter incoming packets.

Anyone guess why stray packets exists?

[Valarauca]

Okay so I found out where the random noise packets were coming from.

Even if I run the fetch in a one shot

Open port, poll for info, then run TCP close. It doesn't actually close the connection (aka FIN in the TCP connection flag). It continues to repeat forever for what I can see.

The master says 00 00 00 00 00 03 00 8F 03

The slave says 00 00 00 00 00 06 00 02 00 01 00 04

The master says 00 00 00 00 00 04 00 02 01 02

The slave responds 00 00 00 00 00 07 00 0F 00 00 00 00 00

And it repeats. I really don't know why, but what ever.

Either way this creates an interesting problem. Because the single port slave deamon continues to alloce resources to this TCP connection even if it should have been closed, by the master (via the TCP Close Connection, so does this actually close the TCP connection?).

:.:.:

I'm attempting to circulate the problem by giving everything a protocol header of 1. Will post if it works.

Edit 1: Apperently I should google before I post, that is a documented error the SERVER needs to close the connection also for it to fully close. Which is easy I guess I'll just close the connection if the length is wrong, I really don't think I can get a MODbus/TCP packet with a length less then 6, which is literally the smallest request I can make. So I'll set it up so that if length is less the 6 "MB Ethernet Recieve.vi" will error, and when an error progates in the slave deamon it will result in the port being closed, and the error being ignored, I guess.

[Valarauca]

And my boss just walked by and told me that our front end is updating to use ports so I don't need to write this system. Eh I'll slave on in my own time I guess.

So I'm just gonna keep posting updates until somebody comes out of the woodwork and helps me, if anyone really can. I'll likely write up something on developer zone when I get this working. The modbus library is 'open source' according to the developers, so I'll like post my modified version when all these bugs are sorted for fellow freetards People who care about software freedom in the community (sorry for the slightly derogitory term, this isn't 4chan).

More info:

So the communication between the daemon and slave start automatically WITHOUT starting it from what I can see. It resumes automatically when the deamon starts up. Which is weird, I checked the MB Ethernet Connection manager.vi which I figured would contain this information. It does have an internal while loop (which doesn't suprise me), but I added empty array constants to it, so at start up it should flush its internal tables. I think.

 Edit1: it didn't work, is the OS keeping the session?

[Esteban.R]

Hi Valarauca

I have not been able to run any test with the library or the VIs that you have uploaded it seems that the master and the slaver are not communicating with each other; probably I am doing something wrong.

Also could you explain a little more what exactly your goal is or what you want to do? I have not fully understood what your application is about or the modification that you want to do to the library.

Regards

Esteban R.

[Valarauca]

Which way are you trying to communicate.

as Main.vi as the  master or the slave. It will function as both.

The idea is to get poll multiple devices, and host their information on a single port. So DAQ's that can't change port can read multipe virtual devices.