dierkens

There's a big difference between sending MODBUS commands to a device that doesn't care what you send it and sending it to a MODBUS device. For testing purposes I'd do as Joe recommended and get the software setup correctly with no errors and then fault it out and see what you get for responses and such. The different errors are going to cause a different timeout. A CRC error for instance is a lot different than a "I can't find the device anywhere" error. One is a pure communication error and the other isn't.

I'd create new projects and test each I/O section. Create one that only has the original block of I/O and test it. Create another one that just has the original block and the 2nd (long) block of I/O. Create a third one that has the original block and the 3rd (short) block of I/O. That should tell you if each piece is operational and it shouldn't take that long to do it.

Make sure the correct MS Windows .net files are installed.

Once that register is set to a value it will continue to have that value until something else acts on it. You have two choices; you can either clear the register on a timed basis, perhaps just before the other PLC sets it, or you can have a routine that 'pings' or keeps track of the communication between the two. This can be in the form of a heart beat setup where one PLCs set a register to the a 1; the other sets sit a 0 and then if the heart beat stops you know the comms has gone down. There are a ton of ways to go about it.

I know this is an old topic, but I wanted to see if there's been any movement on having a 2nd network port available for things like MODBUS/TCP? Right now it's quite a bit of work to get these PLCs onto two (2) networks without having the OT Network group freak out over network security issues.

Does anyone have any tips on getting hardware? We've been waiting 348 days to get UID-1600: 5 UID-0016R: 5 When asked, we keep getting the 'it should be on it's way any day now'. We've got other projects coming up and I'm trying to avoid these long delays.

Make sure you're using the same version number of the Unilogic program as that used in the PLC. That's where I'd start; just to make sure there aren't any version mismatch issues.

Why not just use MODBUS status for everything you only need current state updates on and then have the other PLCs just read/write stuff to each other as needed?

You can use the periodic reads. play around with it and figure out what method(s) work best with the PLC you’re using.

You don't have the project opened anywhere else do you? Verify that all of the files are closed on any other machine.

Re-Install the software.

Thank you. We're updating our projects now.

Does anyone know if this floating point swapped or float inverse has been implemented?

Quick question that I've been asked about a few times by clients and other controls engineers that I have a 'hard time' answering. We assign an IP Address to both the CPU and the HMI but we only ever use the HMI Address for anything such as MODBUS/TCP communications, VNC, FTP, etc. What's the purpose of the CPU IP Address if we never use it for anything? It' nice that the 2 ports are actually into a switch but if we can't really use the other IP Address then what's it for? This tends to come up when we need to communicate/access the PLC over different networks.

I don’t understand the ‘use of replacement’ and the need for UDP in regards to MODBUS. Can you outline this please.