Two rungs writing to one coil

[geniusintraining]

Terry:

As much as I love to debate with you that horse is dead…I just wanted you to know that I still feel the same…but ALL of you win..but I don’t give

Lets talk automation/programming techniques....

 

[Terry Woods]

Git:

So again, What are you trying to say?

 

[geniusintraining]

GIT said
"Terry:

As much as I love to debate with you that horse is dead…"Thats clear Terry, we have killed that subject...remember?


Do you want to talk about programming techniques? I have been think about and trying to research how different people program differently, how a automatic cycle runs, verses scan time.

 

[Terry Woods]

"...verses scan time."

Hmmm...

Are you talking about scan-time... or scan-to-scan? Big difference.

 

[geniusintraining]

scan to scan... the thing that I could not grasp was the speed of the scan vers the speed of the process. the program would scan many times before one step of the auto was complete

I'll start a new thread... I would like you to comment when you get a chance

Thanks

 

[PeterW]

I remember working on a system many years ago, the PLC was an Allen Bradley 1776 (or was it 1774, can never remember when we let you yanks go it alone :nodi: ), the very first Allen Bradley PLC, big black thing.

It had a limited number of timers, so the programmer decided to only use one timer, this beast let you save the preset and actual values of timers.

So every timer was preceeded by a couple of transfers to load the timer data for that use, then the timer itself, then he'd store the actual values back into the words he'd pulled them from.

The only changes from timer to timer was the storage, the timer address was the same throughout.

Good old days, eh.

 

[Terry Woods]

Git...
In Post #27 you quoted me and then just posted a "Smile"... what does that mean?

As far as Scan-Time... the faster the better!

If scan time was 0.000 seconds... i.e., zero-seconds, then you are talking REAL-TIME! In terms of Ladder Code, this is NOT obtainable, but, the closer to zero-scan-time the better!

Now, you gotta know, there is a HUGE difference between Ladder processing and REAL RELAY Control. The difference is in the timing of the evaluations of the various input conditions and the timing of the subsequent output activity.

 

[Ken M]

Hi Terry

Just as an interesting aside, what exactly is your definition of "real time"? Obviously, excluding the mysterious world of quantum physics where an effect can occur before its cause, your example of 0.000 secs is impossible. What would you consider "real time" ?

regards

Ken

 

[Binaural]

Hi Terry

Just as an interesting aside, what exactly is your definition of "real time"? Obviously, excluding the mysterious world of quantum physics where an effect can occur before its cause, your example of 0.000 secs is impossible. What would you consider "real time" ?

regards

Ken

Many PLC applications would meet the definition of hard real time, ie there is risk of damage or system failure if the system takes too long to complete its calculations or respond to inputs. A few might be categorized as soft real time, where performance degrades as processing lag increases but the system can continue to operate.

In practice, I would be satisfied my sytem was operating in real time if the following constraints were met:
1. My processor scans at least twice as fast as the fastest changing signal it must read - counting pulses from a photoeye for example.
2. My system control is stable and acurate
3. I do not see "reaction time" errors, such as inaccurate starting and stopping of a positioning motor

It can be suprising how increasing your processing power can improve the performance of a system!

 

[KEN_KACEL]

in seperate subroutines

I have used multiple OTEs in the same ladder but in different files or subroutines.

With two subroutines I will only be scanning one of the same outputs at a time. I can select which one of the subroutines needs to be scanned with a N.O. JSR1 and N.C. JSR2. This has proved to be very effective for different modes of machine operation when the same controls are needed for sperate modes. I can cut and paste and then write out what I don't use. I hate to do this but it works. It sure confuses the clientle' when they are watching a bit change and the output doesn't(not being scanned).

I have only used this 3 times and it was only under extreme circumstance.Mainly because I could not hace the machine down so I could flip between the new and old logic and not leave edits testing.

 

[Ken M]

Binaural

Thanks for the reply. Exactly what I was looking for - not a mention of units of time anywhere. I think I had expected to see a few posts along the lines of 0.5mS or 100us or 1us or ... But you hit the nail on the head. Real time is whatever your process can tolerate. I hadn't come across the 'hard' and 'soft' variants of real time before. Well done - take a real day's holiday as a reward!

Ken

 

[Rod]

I was taught to use Nyquist-Shannon for sampling rates.
In a nut shell you want at least 2.5 sampling rate per 'unit' desirerd.

So an audio CD is at 44KHz for our 16-20Khz audio perception

Whatever.

Rod

 

[Terry Woods]

Ken M,

My post was directed to Git. I was trying to keep it simple for the sake of explanation. I believe I made it very clear that my post was a comparison between Ladder and Hardwire. With respect to Ladder, I indicated in my post that a scan-time of 0.000 secs is unobtainable. I tried to, at least, imply that you are more likely to get what is effectively a 0.000 scan-time in Hardwire than Ladder, as described below.

In a hardwired application, the speed of a signal is essentially the speed of light. If logical circumstances call for a signal to be applied to one or more output devices, then those devices become influenced by that signal at the speed of light. The devices then respond, each at their own inherent speed.

The point being, in a PLC, Inputs are read, decisions are made, and then outputs are acted on. There is a time-delay between reading the inputs, from scan-to-scan. Then, there is a time difference between reading the inputs and writing the outputs. And that time is less than the total scan-time, but, overall, it is still slower than a hardwired system.

Let's say you have a single input controlling a single output.

In Ladder...
Read the Input, Process the rung, Write the Output.

If the input was NOT on during the last read, and is then seen to be on in the next (current) read, then the input had to have come on sometime between the last read and the current read.

In Hardwire...
Before the PLC detects that the input has come on, the hardwired system is already responding to the hot input and applying power to the output device.

That is the "real-time" to which I referred. And that is the difference that I was trying to point out.

Of course, there is latency in any system (except for maybe those ESP Systems related to Quantum Mechanics). As far as I know, there is no such thing as an INSTANT system, but there is a Real-Time Electrical System that is NOT artificially delayed.

Subtle... but, oh, so real!

 

[RMA]

In a hardwired application, the speed of a signal is essentially the speed of light.

Not if you're switching relays, it ain't!

I'll never forget the problems that we had with race conditions in multi-pole (10 - 20) reed relays in logic circuits for telephone exchanges in the early seventies!

 

[Terry Woods]

RMA,

I'm pretty sure that my example was about "...a single input controlling a single output."

Earlier I said...
"If logical circumstances call for a signal to be applied to one or more output devices, then those devices become influenced by that signal at the speed of light."

This means... as soon as the logical condition is asserted, be that logical condition a limit switch connected to a solenoid, or a relay connected to the solenoid, the solenoid begins to react, at the speed of light, as soon as that logical condition exists.

And yes, in a hardwired system there are bound to be multiple relays between the initial cause and the final response... however, to a large extent, depending on what those relays are for and how they are really controlled, it is not unreasonable to expect that activity by those relays depends on subsequent activity in the process. As such, the PLC version will only add more time between the initial cause and the final response. The more relays/inputs that the PLC has to wait for, the more the scan-time only delays the final result! It sure the hell can't make it faster!

Now... this is NOT to address the ridiculous situation where you have 20 REAL Relays wired in series, thus producing a scaled latency.

Please... Consider the general concept behind the argument... not the rather obscure and counter-productive exceptions.

I agree that ALL systems should be designed to handle exceptions! However, not silly or counter-productive exceptions. In those cases, those exceptions simply have to be removed! NOT IGNORED... but eliminated!