Nightfly

Ethernet/IP is not a "Standard" Ethernet socket connection. I think to talk to this device you need a FX5-ENET/IP module. This is what we use to talk to Ethernet/IP devices such as Inverters / Loadcell's etc.      

If this is a normal rodded cylinder then this would not work as the piston inside the cylinder does not have the same surface area on each side (because of the rod).  So given the same pressure is applied to both sides, the side of the piston with the larger surface area (non rodded side) would apply a larger force than the other side making the cylinder extend outwards.

We use quite a few Mitsubishi drives, however we only control the speed via Modbus TCP as the run is done through a relay (the electrical designer prefers this as he likes to link it in with a safety circuit).  To control the speed we simply write to the min speed parameter no 2. Been doing this for several years without a problem.  

It’s very common for programmers to map inputs and outputs to internal memory (flags) and use these throughout their program rather than raw X and Y variables. If the input or output change then you only adjust one line. Also on PLC’s where the input value can actually change during a scan (Allen Bradley) it’s basically a necessity.

  As AndreasW said, if they are sequential then you can check they are a DWORD. Personally I always use the bits of DWORD's for alarms as it’s easier for the HMI to pull out of the PLC (as they are alarms the polling frequency is usually reasonable quick and needs to be done continually). For example pulling 4 DWORDS is usually much easier for the HMI to read from the PLC compared to 128 bits. Then you just have to check if any of the DWORD’s are not zero to generate the alarm.  

I had not heard about this either - thanks for the share.

We have a function block that increments a DINT off the one second timing flag - counts to over 60 years. Do it in ST and it will copy and paste across all PLC's (one of the best features of ST in my opinion).  

Using UDP On the Fx3U's for comms from the PC to the PLC we don’t specify the actual destination address but use 255,255,255,255 instead. Might be worth a try.

With issues like these i usually plug the serial device into my laptop to see unequivocally whats being sent. Use a serial port monitor (there are free ones around). I personally Just find it easier.  

bGreen := wValue > 2500; bRed = wValue < 2000; bAmber := NOT bGreen AND NOT bRed;

Think this means the input X values in your program do not match the PLC. Basically, in the source they are all off. In the PLC some inputs are on (X0,X1,X2,X10,X13 etc). So nothing to worry about and frankly expected.

Nope, thats all you have to do.

Not done much with the 3G, but if I remember correctly it does not have much in the way of string handling. Normally you would use an Fx3U to do this with the VAL function. You could do it the long way and convert the ASCII by your own code. If it’s coming into the PLC serially then depending on how the comms is set up you may find the data is not always at the same location in the buffer every time (so you have to search for it before you convert it). I have done this before mainly for reading load cell values coming in serially. If you went down this path I would recommend that you set up the PLC so that each ASCII character is encoded in one word (turn M8161 on), as it makes comparing the ASCII characters so much easier. How is the number formatted in the string? What software are you using?

  You can often do this using the HMI as a protocol converter. We do this all the time using Mitsi drives and AB PLC's. However, this is just for simple stuff where we are just changing the speed and the update time does not really mater.  

As glavanov said, You need to reboot the PLC or set the Ethernet module's buffer memory address 1600 to a value of 2 to apply the setting.