How compiled is the code?

[evanh]

Here is my first test program that sits in a single custom function on a "Norm.On" rung.  There is a second DiffUpCustFunction on a 1.0 second pulse that prints the value of "j" to the LCD.  That's the whole program.

What I'm getting concerned about is that the below code continuously cycles at a rate of only 160 odd Hertz.  That is about one hundredth of the pace that I was hoping for.  

This function should compile to less than 40 instructions and if that's running in embedded program space on say a 10 MIPS core then we have a 4 microsecond execution time for this section which leaves 6246 usecs for the refresh cycle of two analogue inputs.  

Code: [Select]

a = adc(1) : b = adc(2) 'Snap readings

i = (i + 1) & &H0f
j = j + 1
dm[i+1] = abs(a - b) 'Insert computed error
c = dm[1]+dm[2]+dm[3]+dm[4]+dm[5]+dm[6]+dm[7]+dm[8]+dm[9]+dm[10]+dm[11]+dm[12]+dm[13]+dm[14]+dm[15]+dm[16]
c = c * 3125/8192 'Convert to mA, (100 / 20 * 5000 / 4096 / 16)

if c > 100
  clrio RUNNING
endif

Evan

[support]

There is a fixed 2ms of I/O scan time each time the ladder program ends and perform and input/output refresh. Even though the program is short, the I/O scan time is fixed. The long I/O scan time was due to the needs to perform software filtering of inputs to eliminate false triggering that can be caused by fast transient inputs. (Software filtering is disabled for the input #3,4,5,6 if they are defined as interrupts of HSC to avoid penalizing the speed). This is the reason why you are not getting short execution time.

Writing to LCD display is also a time consuming operation. The standard LCD display based on Hitachi HD44780 IC has a slow interface and the PLC actually has to slow itself down just to ensure that the data are properly transferred to the LCD each time a SETLCD command is executed (especially the clear screen command). So the cycle time you observed is really much more than the standard CPU execution time.

[evanh]

Cool reply!

But, but, but, filtering can be done over many cycles ... I mean, eek!, I'd never put inline delays in my own dedicated programs so I certainly don't want it forced by the OS.

That said, I think the situation is actually worse still.  I done a little experimenting by removing the bigger lines of code, namely the ADC reads, the sixteen adds, and the multiply-divide.  This got me from the 160 Hz (6.3 ms) up to around 380 Hz (2.7 ms) which is approaching the 2 ms I/O scan limit.  Makes sense and all but not a good figgure for so few commands.

Btw:  The sixteen adds took the lions share of around 2.2 ms.  


Evan

[support]

An experienced control engineer may understand that noise is a fact of life in electrical control system and there are hardware and software means of tackling them.  But for average PLC users, having false triggering of inputs in their PLC can be a downright frightening experience and can lead to loss of confidence in the product. Our goal is always to make the products working reliably in most industrial environment without requiring the users to be experts in troubleshooting for problems themselves.

Also the digital I/Os employs serial-to-parallel shift register and the interface was deliberately run at a slower speed for reliability reason.  All these contribute to the 2ms I/O scan time delay.

TRiLOGI compiles the Ladder+BASIC program into intermediate code and the intermediate code that is transferred to the PLC is interpretted on execution. This keep the code size very compact but execution time is certainly not as fast as a compiled program written in C. It is possibly fast enough for most for its intended application (industrial control, packaging automation, temperature control, etc) but it  is certainly not a speed champion.

High speed applications such as motion control or engine control units (ECU in modern car engine) require extremely fast processors and is definitely not the type of applications where a T100MD+ may be used. These require fast 32-bit processor programmed in compiled C or assembly language to achieve their short response time.  Until we introduce the next generation of PLC with 32-bit CPUs the T100MD+ PLC will not be suitable if high execution speed is the essential criteria.

[evanh]

Hmm ... puffed chest ... cards on the table then.

That was a very quick reply, maybe a bit too hastie, I didn't say not to filter.

Ok.  I understand the compactness of tokenising but compiling isn't going to be much different in size once you account for the built-in libs of the interpreter.  I suspect this really might be an issue of self-programming of program space in the uC or reliability of compiling or recovering from corrupted PLC.  Yep, most(all?) other PLCs also use tokenised code, so I'm not going to say compiling is the best answer.

I do have doubts about your argument that it is fast enough for a PLC, speed is always a concern.   Modern "name-brand" PLCs are getting very fast compared to earlier models, it's a selling point.  Of couse, I admit, with faster execution comes demand for larger program and data space.


evanh's ego.

[support]

Sorry.. didn't mean to annoy anyone. I have reworded the reply above.

[evanh]

Nah, offence wasn't taken at all.  I rather enjoyed the exchange.

It's not often the front tech support is so informative/knowledgeable about their product so I took the chance that I might be able to help with future design improvements which you have just indicated are indeed planned.

As for the filtering, it looks like it won't make a big difference to the T100s but, I ment that the I/O scan itself should utilise multiple scan-cycles of the whole PLC as it's filtering timebase instead of the existing inline delay.  So, the ladder logic still sees nice clean switching and gets a small speed boost to boot.

I do realise any such ideas require reburning the firmware so I'm not expecting enhancements for existing PLCs.

The obvious, but hardware demanding, solution to the serialised digital I/O taking time to arrive is to have some reconfigurable logic (hardware) in the uC that cycles the I/O itself and presents a buffer or full map of the I/O space mapped into CPU space so it can be accessed as full speed local RAM.  Not unlike a UART with a decent FIFO.


Evan

[support]

Thank you for your feedback. We value all customers' inputs and will forward them to development team for consideration.

[evanh]

Just had an online look at some System-On-Chip parts but they are not too suited to industrial apps ... My favorite choice so far is a high-end microcontroller:  http://focus.ti.com/docs/prod/folders/print/tms320f2811.html

This beast has a 16 FIFO SPI and also a configurable serial controller, both of which could do a great job of pacing the I/O transfers with little attention from the CPU.  Or should I say DSP?  

The F2812 has an external bus if more memory is wanted but that will be slower access speed and even then will still have quite steep demands on the external memory me thinks.  There is also the F2808 for a smaller variant and has more serial ports including a second CAN port.

And another neat thing is that all the counter inputs have direction control too so even the ones that don't have quadrature decoders built-in can still do the job with a small amount of external logic, as little as two flipflops per counter, that can easily fit in a single combined PLD.  That's up to four encoder inputs with greater than 1 MHz rating and no processing demand on the CPU.

One down side is the I/O pins are 3.3 volt so it'd be happier if all external wiring was done at 3.3 volts.  This should be doable though, opto-couplers and transistor arrays are happy at that voltage and PLDs are already there.


Evan

[support]

We appreciate your suggestions and feedback.