Analog input to digital output using structured text or one of IEC 61131-3 standard

[drbitboy]

Binary search easily completes in one scan and will typically be the most efficient solution to determining whether a given value is in a list of other numbers. That said, it is still slower than array of Bools, or 32 32-bit integers, with bits sets at prime offsets.

Maximum total scan time when doing the binary search is 2.6-3ms on MicroLogix 1100, where a minimum scan cycle, i.e. doing nothing other than overhead, is 0.7-1.2ms.

 

[JesperMP]

I wouldnt bother with seaching though a list, or checking for prime by a formula in realtime.
Just create these variables:

Real_val: REAL ;
Int_val : INT ;
Int_val_is_prime: BOOL; 
Intval_prime_array : ARRAY[1..1000] OF BOOL ; // that will cost only 125 Bytes

Prefill the Intval_prime_array with the information if the corresponding INT is a prime (TRUE) or not (FALSE).
Then it is easy to pick the result from the predefined array:

Int_val := REAL_TO_INT(Real_val) ;
Intval_is_prime := (Int_val<=1) AND (Int_val>=1000) AND Intval_prime_array[Int_val] ;

Scantime is practically zero.
drbitboy, is that what you mean by 'binary search'.
There is no searching, just a simple picking of the result from the array by an offset.

edit: I see that LD suggested that already in post #7.

 

[JesperMP]

If you create an integer list of primes then that will cost 172 INTs = 344 bytes.
So my suggestion also takes less memory.

 

[parky]

If a 1000 bits with 168 set to true that's a lot of typing although fast with modern processors why all the key strokes & brain hurt I'd stick with my idea, simply copy & paste all the primes off google into an array, check with compares (6 off at 28 intervals) then use the offset to only check those 28 chances are it will be anything from 1 to 28 iterations.

 

[drbitboy]

drbitboy, is that what you mean by 'binary search'.
There is no searching, just a simple picking of the result from the array by an offset.

edit: I see that LD suggested that already in post #7.

No, a binary search is a binary search; it's how we locate a specific page in a book; e.g. see this link, I only implemented it in response to @parky's semi-linear search.



LD's approach was the first I implemented in response to that post (look for the phrase "constant-time lookup"), but rather than loading the primes as 168 or 172 bools out of 1000 or 1024, or 168 or 172 INTs in a list I showed two easier ways to set up the data: 32 DINTs at 32-bits each provides 1024 bits; calculating the primes in the PLC on the fly using the Sieve of Eratosthenes in about 1000 scans when it starts up.

 

[drbitboy]

If a 1000 bits with 168 set to true that's a lot of typing although fast with modern processors why all the key strokes & brain hurt ... from 1 to 28 iterations.

If someone is going to enter the values by hand, then why not do it with only 32 INTs or UDINTs with 1024 bits that can be copy-pasted from the 'net, or from the output of a short script, or generated in the PLC itself in the first second of RUN mode, and also get the benefit of a primality lookup via a far faster, far less complex, far fewer (by an order of magnitude) three instructions or perhaps 1?

Or if they prefer using @parky's (and my) slower setup of a sorted list of primes and the arduous () copy-pasting of 168 INTs, then at least use the faster and less complex binary search to save at least a dozen iterations per lookup to boot?

Even doing the divide and checking the remainder is faster and less involved than a semi-linear search, and only involves manually entering the first eleven primes, which can be done in about a minute.

But y'all just trollin' me now, so I am happy to return the favor .

 

[drbitboy]

For that matter, even this "find a prime via the definition of prime" algorithm is faster and less complex than any other-than-binary search of a list comprising over a gross of sorted primes:

​

 

[parky]

Not arduous at all, I copied a list off google that happened to be the primes in 0-1000, these happened to be separated by coma's so easy to create a CSV then port them into the array took about 30 seconds.

 

[drbitboy]

Not arduous at all, I copied a list off google that happened to be the primes in 0-1000, these happened to be separated by coma's so easy to create a CSV then port them into the array took about 30 seconds.

That's still a lot of work to set up to use the penultimately slowest lookup method.

N.B. the same (available on the net, comma separated) is true for the 32 UDINTs with bits set to 1s at prime values' offsets, and the execution time for the lookup is at least two orders of magnitude faster, as well far less complex, in some cases a single instruction.
_

 

[parky]

28 iterations is not slow, done bigger ones than that, why the need to squeeze every microsecond out of a PLC when it's not even anywhere near close to being pushed. how long would it take to set the bit pattern of 168 bits in a thousand bits in the right order without a mistake ?. not as quick as copy & paste in two operations.

 

[drbitboy]

not as quick as copy & paste in two operations.

If you can copy & paste 168 primes in one go, you can also cut & paste 32 UDINTs cf. https://bbs.csdn.net/topics/398497644#413563939.

And the code to use those bits is far far far simpler than your semi-linear search, and it is even simpler than my binary search.
_

 

[drbitboy]

28 iterations is not slow,

No, of course it's not, but it's at least four times slower than binary search, and more complex than it needs to be.
_

 

[parky]

Here is a ST routine run on the PLC to populate the prime numbers from 0-1000 in an array at start up i.e. on first scan this elevates the copy & paste, it also means that if for some reason the primes got corrupted or the program re-loaded without update of the original data a power down & back will restore the values. (only requires 168 length array).
This could be adapted to generate the is prime bit pattern in an array of 1000 bits, thereby using indirect pointer to the relevant array bit to test if true.

 

[parky]

Here is the bit version for generating the 1000 bits in the array are set to true if it is a prime number or false if not, by using the analogue value as a pointer to the location of the array
i.e. IF Prime_Array[pointer] = TRUE THEN
no need for a loop so fast just as the idea posted by DR:
The prime bits generator function could be called on first scan or in a pre-scan program.
Note: Could have reduced this to less instructions but simpler to just modify the other.

 

[Steve Bailey]

This being a PLC forum after all, and after 44 posts with almost no feedback from the OP, can anyone suggest an application typically served by a PLC where determining whether or not an integer is prime would be critical?