Need lower scan time for a couple rungs

[PLCwannabe]

 I have an average scan time on a brx (DM1E-18ER3-D) around 5 milliseconds. There is a process (analog input) (about 3 rungs of code) that I want to read every millisecond. Is there a way to do that? Also the analog input spec is listed at 1.2 mS. Does that mean that the analog input is read every 1.2 mS?

[franji1]

I have an average scan time on a brx (DM1E-18ER3-D) around 5 milliseconds. There is a process (analog input) (about 3 rungs of code) that I want to read every millisecond. Is there a way to do that? Also the analog input spec is listed at 1.2 mS. Does that mean that the analog input is read every 1.2 mS?

That is within the analog module circuitry itself.  It does not get published to the PLC except during the I/O scan, which includes the logic scan too.  So the fastest you can get is the SLOWER of the two times, in your case, that's 5ms.  If you had a PLC scan of 0.8ms, the analog would update almost every PLC scan, but not quite.

In addition to logic, communications slows down PLC scan time.  If you are dealing with larger strings and buffers that you are copying or searching, those take time.  FOR/WHILE loops with large .TimeSlice values lengthen the PLC scan.  Do you utilize a lot of strings or large buffers or that you copy or parse, or looping?

Profiling
You can "profile" your code by utilizing two MATH instructions with TICKus() - microsecond counter to help figure out what you can possibly optimize (no need to optimize the already fast code - Pareto tells you to look at optimizing the slower code).

MATH D0 TICKus()
rung or rungs doing some big thing with strings or buffers or parsing or for/next looping or
MATH D1 TICKus()-D0

D1 will contain the amount of time doing "some big string thing".

See where your PLC scans spend most of the 5ms.  Sure, the MATH and TICKus has some overhead, but it's very small compared to the "slower" code you are measuring.

[PLCwannabe]

So an interrupt code block would not work in this instance?

[franji1]

So an interrupt code block would not work in this instance?

So sorry I never responded.  Analog does not support any kind of HSIO functionality (interrupts fall in this category).  Even though you could technically look at the analog values in a timed 1ms ISR, the image register values would not actually be updated except for the normal PLC Logic I/O scan (every 5 ms).

In this situation, the only way to get 1ms update on your analog is to get your PLC scan to be around 1ms.

Since there is no HSIO Analog module, you could "create your own" by doing it with another BRX -M (or MPU with onboard analog?) doing JUST the high speed analog I/O processing (3 rungs, nothing else or very little else).  Of course, this is only useful if your "high speed analog processing" does something with it, and we may just be kicking the problem "down the road".

Based on what you need to do with this high speed analog information, that would dictate whether moving the analog prcessing to a separate MPU even makes sense.

If you are logging information to a file, the RAM drive is much faster than SD card (if that's part of your "processing").  If so, this is definitely do-able. 

However, even in a separate PLC, scan time is still critical for the 1ms processing.