Serial Vs POM and TCP/IP for modbus

[Ingeniero]

I want to buy a BRX for a high speed process that needs to have consistent scan rates.

I dont need internet to the PLC, only mod bus, but I like modbus TCP/IP better than serial. Most laptops and PCs dont have a serial port any more plus and the Cat5 cable is easier to come by. I know I can use USB serial but its another thing to buy and wire. I am looking at the POM EcomLT installed in a BRX with no ethernet port.

Since the most important  requirement is the process need for consistent scans should I go with serial or the modbus TCP and the POM ECOMLT?

[ATU]

I would try the EcomLT POM first. It is important to set the update rate on the communicating device at a lower than normal rate. For instance, if you are using the CMore or Cmore micro, in the PLC  device settings, set the Modbus Polling rate to 0.5 sec or greater depending on what your application can handle. If that won't work then go serial.  If you want to have a repetitive scan of your code in the microsecond realm, use the timed interrupt feature to run your routines. Check the latency and Execution properties of your interrupt routine to monitor if your code is executing correctly. If you are talking milliseconds, the BRX should easily be able to handle it in the normal PLC scan. The use of stage programing and only enabling tasks when needed will make your code execute more efficiently and keep the scan time at a minimum.

[Ingeniero]

Thanks ATU.

I need a steady 10 millisecond scan rate. 

I think I will get a BRX without an ethernet port and then add a ECOMLT POM. the serial port on the HMI PC only allows one program to control it at a time, right?, so I wont be able to force the PLC from the DOmore software and monitor the HMI if I only use serial comms?  I can put both the HMI and the PLC on Modbus TCP or the HMI on serial and the PLC on MODBUS TCP.

after I get the layout of the comms right I can test the scan rates.

[BobO]

What needs to be fixed at 10ms?

[Ingeniero]

Hi Bob'O

The speed and acceleration governors loop, the field IO can be faster, need to be done at 10 MS.   So comparing the setpoint to actual from the analog imputs  and calculating the error, going through a low select gate multiplying by the gain and doing the integral  and signal conditioning to the output all need to be done at 10MS.  This is the standard I have seen used at several turbine control system makers.  AB evens says certain functions like integral need a constant scan rate.  If you want the turbine to operate at +- 2 RPM at 3600 RPM things have to be steady and consistent.

Now using the simulator I just put all the logic in tasks blocks and set the time to 10 ms, I dont know if this is the best way. I am going to wait for the PLC to start optimizing scan times.

Thanks

[BobO]

If your computations take time into consideration, the scan can vary and the result be just fine. You can access the exact time in microseconds through the MATH box function TICKus().

[Ingeniero]

ooh, so instead of relying on a precise scan rate use tickus in the calculation. Great, now I have to check this out.

[BobO]

ooh, so instead of relying on a precise scan rate use tickus in the calculation. Great, now I have to check this out.

I'm sure the math for constant scan is simpler, but TICKus() can give you a very precise time to use in a calculation if you can tolerate the increased math complexity. Do-more does math well, so that shouldn't be a problem. Then you really don't care what the scan time is.

Where is your input data coming from? Precise time is only relevant if you start with fast measurements.

[Ingeniero]

https://www.rammeter.com/media/specsheets/Jaquet_T400.pdf

read the second page of the scan times and the delay for the 4-20 signal (7.5MS) I have seen these work for control when set to  5 and 10 MS. There are also frequency cards available in Allen bradley, Ovation and I think GE fanuc which work.

The t401 module is $300 to 400 or so.

The signal from the t401 would go to your new high speed analog card.

If this works and  is price competitive with for example the woodward 2301 diesel engine governor it could open a big market to PLCs. The woodward 2301 is a dedicated controller in most diesel generators in the USA. There are other examples of rotating equipment governors which the DOmore might be able to replace.

I started out wanting to do this myself  but now I figure the more the merrier. If someone else is successful i can use their experience to sell my version.

[Bolt]

Seems to me that device is excessive.  Just mount a sensor near the engine's flywheel and count pulses with a BRX?  Save another ~$500 bucks in hardware.

[BobO]

Any chance you can get a pulse directly off the shaft? If you bypass the the converter, I'm sure you can tighten this way up.

[BobO]

Seems to me that device is excessive.  Just mount a sensor near the engine's flywheel and count pulses with a BRX?  Save another ~$500 bucks in hardware.

Exactly this.

[Ingeniero]

Seems to me that device is excessive.  Just mount a sensor near the engine's flywheel and count pulses with a BRX?  Save another ~$500 bucks in hardware.

might work. But I would be testing it while the jacquet module is tested and proven.  Is someone else using the BRX counter for speed input to a governor?

[BobO]

Seems to me that device is excessive.  Just mount a sensor near the engine's flywheel and count pulses with a BRX?  Save another ~$500 bucks in hardware.

might work. But I would be testing it while the jacquet module is tested and proven.  Is someone else using the BRX counter for speed input to a governor?

I would be amazed if the BRX didn't greatly improve the result. There is zero chance that converting speed to analog and then reading the analog will produce better results than converting directly to speed in the PLC. Look at the PLC's HSIO *timer* function. You can convert microsecond shaft rotation times directly to RPM. If it jitters more than you like, throw a little filtering on it.

[BobO]

I set up a PWM output to generate a 60Hz (16667us) pulse at 1% duty cycle. I looped it back to a high speed timer operating in Free Run mode with a 50000us timeout, and then applied an Interval scale to RPM. Then I tweaked the interval to 16666us, 16667us, and 16668us to show how that affected the input.  The converted input frequency is shown in the trend view. It is moving a maximum of 1us. You can't see it, but it is updating at 60Hz.

I would expect the jitter to be a bit more than this, depending on the stability of the shaft input, but what I'm showing you has *zero* filter. A little filter will take out that jitter.