Internet PLC Forum

And if you want rounding to nearest, instead of rounding down, it changes in detail but not really all that much:

square=12345678 ' The number we want to find the square-root of.
sqroot=0 ' The resultant square-root.
index = &8000 ' The bit mask indexing.
check = 0 ' The lookahead sqroot - Added for faster execution.

sqrt_loop:
  check = sqroot + index
  index = index >> 1
  if (check * check - check) < square then sqroot = check
  if index<>0 then sqrt_loop


Evan

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

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

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

TBASIC is effectively controlled by the Ladder Logic.  So you basically have a bunch of BASIC subroutines that are called from the ladder and can call each other.

It's not an either/or situation, rather TBASIC is used to perform data processing when the right logic becomes true.  Eg:  Checking voltage levels on the ADCs, performing math and string handling, issuing motion commands, updating the LCD, managing slaved communication devices and plenty more.


Evan

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.  


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

I'm not sure what's going wrong but having just written me first program for a T100MD+ I am a bit green on what's legal code and the procedure for downloading to the PLC.

What I've found is that using a custom function as an input bit in the ladder is not valid code.  A couple of interesting effects occur if one tries to do this:
 1 - The simulator compiles and runs without complaint.
 2 - The real PLC download doesn't even appear to attempt it's compile cycle and therefore doesn't send any code either.

So, apart from the discrepancy in the two procedures, there is no error or warnings produced by any of the compile runs.


Evan

Right, a quick google got me this, http://www.serialio.com/support/jspInstall.htm
It appears to be a commercial product that TRi will have paid for, https://serialio.com/store/advanced_search_result.php?keywords=serialport

I'm not too keen on purchasing this only to find it's not the complete fix.


Evan