LabVIEW
Ethernet drpos connection.
@FrankHS wrote:
- Why do you have all that duplicate code?
Do you mean the write - read sequences? There are three of these. Each one writes to a module on the IO rack. First we generate the hex sting to write, and then write it to the Ethernet port. When we read it, there is a reply back from the rack controller It is always that 96 byte string which contains the state of all inputs and outputs. If my string is corrupted, the controller won’t send the 96 byte string.
The first two pairs (DO) only differ by a string and boolean array, so you could use a FOR loop autoindexing on a string array and the boolean array reshaped to two rows of 16 bits
Here's ow that could look like:
@FrankHS wrote:
- Does the remote device require a specific local port (62140) or will it reply to whatever the source port was?
I’m not sure. I think it was in some documentation I saw. I never tried any other port.
You could try a local port of zero and see if things still work. This will guarantee that a free local port is picked, while in your case you might run into problems if the port is already in use. It depends on the remote device if things will work with a random return port. Worth a try.
I really think that 25ms is a bit short, especially for UDP open. Maybe there are also race conditions if that same port has been closed only a nanosecond earlier. Maybe you should also be a bit more selective and treat different errors differently (e.g. timeout error vs checksum error vs udp open error, etc.).
Starting from scratch I probably would also redefine (invert) most of your boolean outputs. You mostly have success=true while in the world of programming it would be more consistent to define failure=true, consistent with error handing elsewhere. This simplifies the logic!
