Is there or should there be a RND instruction

Goody

Member
Join Date
Apr 2002
Location
Huddersfield W Yorks UK
Posts
1,081
Dear all,
I would like to ask if anyone knows of a brand of PLC that has a RND or something like instruction.
RND meaning 'random' as in the BASIC instruction.

Something like move a value into a data register + RND where RND is given parameters such as between 6 & 50 so that a random number between (in this case) 6 and 50 is added to the original number. (or used on its own)

I ask this because I have been given a project where the customer wants a dying machine to randomly dye yarn passing under some dye heads.
(It is sort of a printing machine)
I wrote the original software for this machine and it has run great for a long while. But they tell me that sometimes they are having trouble with the knitting machines.

When knitted, the finished garment should have completely random colours in it.
Sometimes, because of the linear action of the dying machine, the colours in the finished garment are blocking together.

I have got around the problem with a sort of pseudo randomness. In that, the operator now inputs 6 random figures per dying head into the HMI
These are saved in 6 consecutive data registers per dying head. I then used index registers to alter the dye length each cycle.

It works and I could increase the amount of random numbers for a bigger random effect. But with 4 dye heads using 6 data registers each and more dye heads planned for the future I could run out of data registers.
The math(s) for the program is already using hell of a lot of data registers.
This problem is already solved and ok, but it is an example where a RND function could be used.
These special (ready made) functions are always used to save long lines of logic.

Does anyone know of a brand that has this function or does anyone think it would be a good idea to include this function in future models.
 
Random only comes in nature. The thrue value of any mathematicly generated random number is predictable. What you only have to be concern about is "Does it mather, will they see any difference".

In casinos, a lot of games like Keno are math-based random generation. Here in Montreal, a few years ago, a math professor sat down with his papers and found the algorythm generating such far fetch values. He got to keep his 250 000$ won before they stop the game...

If a human being generates it, another one will find how.

So what you really need is something which generates a sort-a ramdom number. A number whit such randomnes that, to the naked eye, a dyed patern on cloth or so, would not be easaly discovered.

I'm sorry to tell you that your task is of the hardest one. Paterns and colors are the source of many scientific developments... specifically about the real nature of randomness. Take a look at the origin of fractal mathematics. They come from the belief that colored paterns, even in nature, could be predicted.

Easyest way to have it... use MANY registers. Write to them real random numbers from a chart. Use them one by one.

They'll never see the difference. They will in fact have real random numbers. Those will only have been "chosen" by you.

The question is "How many numbers do you need?"

Remember that thrue ramdomness will also give you color closely matched. It's normal, it's random. Equality or something the eye thinks it's identical, is also "random".
 
I don't know of any that have a random instruction maybe someone else does.

I sthere any reason you couldn't use free running timers and take a "snapshot" of the accum value right before the process starts for each piece? Probably about the most "random" way I can come up with.
You could add a limit instruction to let the timer run until in a preset range so that your gauranteed to be between 6&50. I think I would run the timer in millisecond and divide the acc by X to achieve the best results. Maybe even a double divide?

Drewcrew6

Okay that post just beat me. but gave me another idea. use the timer with acc. Just use it to call a set of predetermined set of "randomness" (a particular register). That register musthave all possible combinations, a chore in itself. You could even add monitors to gaurantee all combinations get used.
 
Last edited:
If I wanted pseudo random number generator I would consider LFSRs

pseudo random binary sequence using a linear feedback shift register

LFSR use a few SHIFT and XOR functions. A 32 or 31 bit LFSR should be easy to implement on a PLC. Imagine having a sequence where all the numbers between 0 and (2^31)-1 appear only once!

There plenty of information web about LFSRs. Also search for LSFRs because of misspellings.
 
Thanks for the answers so far.
Pierre enlightened me to the fact that ‘randomness’ is a scientific study. These are good excuses when I am asked why I cannot make them completely truly random.
Even before the alteration to the program I told them that they would never get two knitted garments exactly the same. (I hope I was right)
I thought about taking a snap shot from a timer but the heart of this machine is an constantly running encoder. Everything is synchronized to this encoder.
I thought that it might pull the same value up every time or very nearly the same value and I wanted a wide range of variance.

To clarify what this machine does; it runs about 200 strands of wool (yarn) underneath rollers that lift up and down dying the yarn as it passes. The result is what I would call as a layman in textiles, stripy wool.

At the moment it can have up to 5 stripy colours; the four dye heads + the base colour of the yarn (no dye) Theses stripes can vary from 25mm to any length but usually a maximum of about 300 mm.

I was ambivalent about who should control the randomness, me, the operative or the plc. There was something I was uneasy about with a random function. It seemed to me like I was not in total control of the outcome.
When we program, we do not want any unexpected results.
In the end I decided that the operative was the best person to chose. He of course is governed by his superiors and they often chose the numbers.
I thought it was a good real world subject to throw in the pot.
 
This particular problem brings to mind the very old question (that is, it was asked and answered a couple hundred years ago) of, What is the smallest number of colors (we call them "colors", not "colours") that are needed to color the countries on a map in such a way that no two bordering countries have the same color.

It's kinda like looking at your problem, Goody, from the opposite end, sorta.

Looking from the answer-end, it's very simple.

If a particular country is surrounded by an even number of countries, then simply alternate two colors as you move around the particular country. The surrounded country will require a third color.

If the particular country is surrounded by an odd number of countries, then use three alternating colors as you move around the particular country. The surrounded country will require a fourth color.

It really works! Look at any world map!
(Take a look at all of the countries on Russia's border!)

It is not possible to use fewer, nor is it necessary to use more, than four colors.

Now, the solution to that problem does not require any sort of randomness; although, on first thought, that would seem to be the general direction to go for.

This particular problem requires some sort of highly regulated "chaos".

That is, that last thing you want is randomness!

In order to produce a so-called "randomness", at least, for this particular application, you need to apply an, apparently, highly regulated form of "chaos"! Which, of course, is not randomness at all!

You are using 5 colors and no color; essentially, 6 colors.

Since the problem is to have no "grouping" of colors, and you have 6 colors available, you seem to be in a much better position than the map-makers were!

I'm too far gone into the MGD-Experience to be any more effective at this point... so I leave the idea open for exploration by others.

Those that are into math ought to find this a really interesting problem. Not from the point of view that you expressed, Goody, but from the other end!

This is a great, intellectual, problem! This problem is NOT beyond the grasp of some of the folks I've seen here!

I have no doubt, what-so-ever, that Goody is taking the wrong approach!

This is NOT a RANDOM issue at all... It's a case of highly regulated chaos!

An aside.... (Tangent, as it were...)
This is like the case of the bad transformermer design... what do you do with that? Make a bearing heater!
 
That's what made it a bad Transformer!

Transformermer = Bad Transformer! (or, at least, not such a good one!)

Snort! I just blew MGD through my nose! Now I gotta wipe the damned monitor clean... what a mess!
 
This is not a great intellectual problem.

Terry Woods said:
That is, that last thing you want is randomness!

Those that are into math ought to find this a really interesting problem. Not from the point of view that you expressed, Goody, but from the other end!

This is a great, intellectual, problem! This problem is NOT beyond the grasp of some of the folks I've seen here!
The randomness is required to keep from 'coloring the map' the same way each time.

This is not really a math problem. It is more of a puzzle and is definately not a great intellectual problem.

As stated one can color the adjacent areas using random colors until two adjacent areas are found to have the same color. Now here is the trick. One must be able to back track, undo, or rip up the last areas mapped and new combinations tried until all the areas are colored. This is not unlike a chess program only very much simpler. Actually it is closer opimization programs that try to get the greatest number of patterns out of a piece of material.

I use to do this sort of thing just for fun.
 
I used to make use of the (pseudo)random sequence generated by an old Sinclair Spectrum computer. Since I have the complete assembly listing of the system ROM for this one, I regularly translate bits and pieces from Z80 to PLC if I need computerlike calculations.

In this computer the random genarator worked as this:

- take a number (the seed)
- add 1
- multiply by 75
- take the remainder after division by 65537
- subtract 1

The obtained number can be used as a pseudo random number. You also use this new number as the new seed. I have made an Excel file which does this calculation. Drop me a mail and I'll send it to you. Then you can test it by inserting any number between 0 and 65535 in the green field. The calculus is made in decimal with a conversion to hex, to see how it's done in a PLC program. If I know what PLC you're using I maybe might translate it for the PLC in question, provided I have the soft.

Good luck with it!
 
I might not have explained this project too accurately.
The randomness I am looking for is in the length of dye applied
to each stripe.
Originally, this machine would dye 4 colours in the same sequence
all the time. (If 4 colours were chosen)

So you would always get RED YELLOW BLUE GREEN in that order
every time. (The die pans can be changed to change the colours )

If 50,50,50,50, was entered from the HMI then those colours would be dyed in that order throughout the length of yarn at 50mm each.

The blocking of colours only occurred when the yarn was knitted into garments.
And then only with some types of garments and even then very rarely.

It was sort of a fluke that the knitting machine started with the yarn at the exact spot where blocking of colours would occur.

To stop this ever happening again I was asked to make the individual dye lengths random on every dye, every cycle.
So that 50,50,50,50 would become 50+RND 50+RND etc every cycle.

The mythical RND would then be given parameters like 0 to 20 so that each dye length could range from 50mm to 70mm. This in theory would stop the blocking of colours.
This is where I used 6 Data registers per colour to alter the lengths
in a 6 times repeating cycle.

We are talking about the fickle fashion trade here.
I was shown some of the garments (Pullovers in this case) where blocking had occurred. I thought they looked great and would have bought one.
The colours sort of spiraled around the body, it was a brilliant effect. But no, they were rejects when they came out like that. They were just not vogue.

Ironically, I programmed the original machine exactly to spec.
It was an R & D project to see if it could be done.
Everyone was delighted with the results for months until this blocking thing.
Now I was the villain and this blocking was being blamed on me.

I am very interested in the Z80 code being translated to PLC code. The PLC I used was a Mitsubishi FXon.
 
Peter said...
The randomness is required to keep from 'coloring the map' the same way each time.

The "intent" of the randomness is to prevent "color-clumpimg".
If you use a Random seed for map-coloring you most likely WILL get "color-clumpimg"!

If you wish to not color the map in the same way, then, use a different color set!


Peter said...
This is not really a math problem. It is more of a puzzle and is definately not a great intellectual problem.

I certainly did NOT mean that this would be a GREAT intellectual problem in the sense of proving "Fermat's Last Theorem" (which has been proven just recently - in the last several years).

Proving "Fermat's Last Theorem" certainly would be (and certainly was) a GREAT mathematical feat!

I meant that this would be GREAT in the sense of GREAT FUN as a mathematical exercise.


Peter said...
As stated one can color the adjacent areas using random colors until two adjacent areas are found to have the same color. Now here is the trick. One must be able to back track, undo, or rip up the last areas mapped and new combinations tried until all the areas are colored. This is not unlike a chess program only very much simpler. Actually it is closer opimization programs that try to get the greatest number of patterns out of a piece of material.

What you are suggesting is that the processor "hack" a solution!

If civilization had used that approach to problem solving we would NOT be posting messages on PLCS.NET! There would be no W.W.W.!!!

All of the earlier mathematical leaps would not have occurred!

How could they? Take 200 monkeys and give them pencils and paper. Do you really think that any of them could develop Newton's Laws? The Laws of Thermodynamics?

How long do you think it would take to get "E = mc^2" out of our Math-Monkeys? And, even then, what the hell would it mean to anyone?

That kind of "hacking" does not provide a solution. It only provides a limited number of discovered cases (maybe) where the aim is seemingly obtained. It is not an all encompassing solution.

The 4-Color map IS an ALL ENCOMPASSING SOLUTION! It will work EVERYTIME!



Now, the problem with Goody's description is that I don't have a mathematic model of how the material is processed into the final product.

As far as coloring threads... how about...

AAA
AAB
AAC
ABA
ABB
.
.
.
CCA
CCB
CCC

27 varieties, using only 3 colors. The longest length of color is 4-units.

If you use 6 colors, then there are 46,656 combinations before a repeat.

Ideas?
 
A hack?

There are many problems that can't be solved using a formula. Many of these can be solved by the recursive search using trail and error. What does a computer know about chess or optimizing wood? Nothing. Computers just execute instructions. Computers just happen to more focused and a lot faster than 200 monkeys. Still trial and error is a valid technique.

You would be surprised how many problems are solved by intelligently guided 'hacks'.

Now that we both know that Goody's problem has nothing to do with coloring a map it doesn't make any difference.

Back to the random number generators. Did anyone check out LFSRs?
 
This takes me back a way but around 1980 I worked at a manufacturer who used the old TI5 PLCs. We had one hanging around in the shop doing nothing, a set of 8 AC outputs and a bunch of strings of Christmas lights. (Did I not this was late December?) The guys wanted randomly flickering lights and asked me if I could program the PLC to do that. I had read somewhere about LFSR's and implemented one in the PLC then used the shift register's bits as outputs. I didn't know which bits to feed back so I had a grand time experimenting (it was a slow time of the year) to get the longest sequence. I quickly found out that if the shift register ever totally emptied that the whole thing would stop so I had to test for that possibility and then inject a bit into the register to get it started again. Maybe I should have patented this seeing what is available nowdays for a couple of bucks, but it was a great learning experience anyway.
 
Terry / Peter

I seem to remember that while the Four Color Theorem was known to be true (like Fermat's Last Theorem), it wasn't proven true until about a decade or two ago

The approach that the 'proof' took (again this is from memory, and I'm no methematician), was to prove that there were only a certain number of possible combinations (I think it was something like 1500) that any map could be reduced to.

They then did a brute force ('hack') on that reduced set of 1500 and showed that 4 was the minimum.

<hr>

Goody

Hand on to your original code that generated the repeating spirialling pattern. Sooner or later some designer is going to say that "random is out - pattern is in" and you'll be required to make the acceident happen deliberately.

Isn't the term for that "stripy" color OMBRE?

Your formula is something like
<center>DYE_LENGTH = 50mm + (random number between 0 and 20)mm</center>
right?

And currently, you have the operator enter 6 "random" (actually, "arbirtrary") numbers for each dye head, and then you cylcle between each number for each head.

This gives you six different length per head, but the pattern repeats every six cycles.

Why not use a common bank of random numbers, with the bank size equal to a multiple of the number of heads, plus one ?

So that when doing the first head, you use 50 + random_number_1, the second head will use 50 + random_number_2, and so on. When you reach the end of your random number list, you'll be using head 1 (that's what the 'plus one' was about). On the next cycle, head 2 will use random_number_1, head 3 random_number_2, and so on.

The pattern will take longer to reapeat (if you had the same 24 'abritrary' numbers (well, 25), each color would have 25 different lengths before repeating instead of only 6 like you have now.

If you want a real random number generator, Pierre is right - only nature is random. But I've noticed that the PLC scan time fluxuates a little bit. And the real-time clock (seconds, or msec if you've got them) is always changing. Multiplying those numbers together exaggerates the differences of both. Taking the SINE of that product can produce a fairly random number between -1 and +1, which can then be multiplied by a constant to give a pseudo random number between 0 and X.

I don't know the capabilities of the Mistu FX, but if you got some of the higher math functions, use those. What you want is to exaggerate small deviations that nature provides even reliable things like PLCs.
 

Similar Topics

Hi, I am working on automating an industrial fabric shrinkage tester to replace its outdated electronics with a PLC. To get the tank's water level...
Replies
14
Views
501
In a control System, I need to move 3 motors attached to roller in stages with speed of 1 to 2 RPM and the torque of motor should be 8-10 Nm...
Replies
0
Views
816
Hi, I want to build a production line project using a PLC. This is the project page...
Replies
14
Views
2,058
See picture. I want to add a rung (magenta) into the existing code. Can't figure out how to do this. I select a -||- , right? When I drag/drop...
Replies
21
Views
1,692
Sorry for the basic question: On my HMI, I've created a button labelled SAVE to save the current values (distances in mm). It's not linked to any...
Replies
22
Views
2,132
Back
Top Bottom