how best to create these pulse signals for a sim program s7-1200

[hadwll]

Long time reader first time poster.

I have the following pulse signals as attached generated by an OEM machine.

I am aiming to recreate the waveforms in order to test another program I have developed as an add on. The top 2 wave forms (product holders) are constant on the machine. The bottom wave(represents a product present in the holder) is more likely to be high or low.

I have created some logic with a myriad of timers and set bits but it is not robust IMO or constant. It would probably do for testing tbh, but this has me thinking surely there is a better way.

I have looked at enabling the system and memory bytes as a clock but it is constant, can it be manipulated?

I'm looking some inspiration and direction to reach a half decent solution.

[L D[AR2,P#0.0]]

What logic are you using to create the green trace?


Post your traces from the plc for the top two showing what is not constant/robust

[parky]

From your description it does appear to be a bit shift system, but I do not understand the waveforms the way I interpret it is that the top ones represent a product in a location (to me this is bit shift register pulses) the bottom one would be if a part is present in the shift register. so in reality the waveforms do not give the relevant information.
For example a rotating table with say 12 stations has an encoder or some form of pulse counter so as the table rotates if a part is present and loaded at the first station then as the table rotates it shifts a true along the bit shift register.
the 12 stations could represent 12 bits so one bit per station if on rotation a bit in the shift register is true then you know it has a part. it could also have a hundred bits and every say 10 bits is a station. I think we need a bit more information. If my idea is not what is actually happening then I think you need to explain the process a little more.

[cardosocea]

I don't think anyone will be able to create this without an understanding of what the system really is and situations you want to simulate for logic testing.

[drbitboy]

Welcome to the conversation!

It looks like the vertical grid lines are at 0.200 intervals.

• Are the units seconds or something else?
• What is the required accuracy of the timings of the synthetic signals?
  • Is rate accuracy important?
    • I.e. the system, and especially the top two pulse trains, appear to have a fixed period of 0.275; how closely does that need to be sythesized?
    • Could an alternate period be used e.g. 0.250 or 0.400, if the entire system were re-adjusted to it?
  • Is intra-signal relative edge timing (pulse duration) important?
  • Is inter-signal relative edge timing important?
    • Rising edges, falling edges, or both?
• The bottom green signal trace appears to have more variability, both in phasing relative to the more regular upper traces and in the presence or absence of 1s
  • Is there a model for this variability?
  • Would a model require a random number generator, or would a limited, pre-generated sequence of random numbers be adequate?

Obviously the model will be limited by the timing accuracy of the S7-1200, and the inter-scan timing, which can be variable. Repeating timers in the continuous main OB are non-deterministic and have some intrinsic noise; perhaps that could be useful for the rising edge of the bottom task.

Scheduled tasks (A-B terminology, sorry) would be one way to cut down on the inter-scan variability, but could a task be run at 1ms intervals if that was the accuracy requirement?

Pulse duration is another issue; I think monitoring the accumulated time, .ET, of a TON would be the best way to handle this.

Originally Posted by hadwll

but this has me thinking surely there is a better way.

... and don't call me Shirley (couldn't resist ).

[BryanG]

A question to the Siemens experts. Couldn't this be achieved using the Pulse Width Modulation function? I am used to Pulse Train Output but haven't used the CTRL_PWM (Pulse width modulation) function, and so am not familiar with the settings available in the associated DB. If the ONs and OFFs were of equal length I would say use PTO, but this looks very much like a PWM signal. PWM works outside the PLC scan rate, so is not limited by speed of timers.
You would need a DC/DC/DC type PLC, or you can add DC outputs but they only seem to be NPN rather than PNP, and so would need conversion.

[BryanG]

Answering my own question, yes the PWM function should do what you want. I didn't know if you could change the width of the pulse and the cycle time of the pulse, but you can. This is from the TIA Portal online help. And you don't need to make changes in the function DB, just use the Hardware IO Address.

[Peter Nachtwey]

Originally Posted by BryanG

A question to the Siemens experts. Couldn't this be achieved using the Pulse Width Modulation function?

What about the phase relationship between the first and second pulse stream.


I don't think a PLC is the right tool for this job. I would try a Raspberry PI or similar.


I know that if I used my relatively expensive motion controller it would be done by now but you guys will waste much more time than the cost of the motion controller trying to make the PLC work.

[hadwll]

Originally Posted by drbitboy

Welcome to the conversation!

It looks like the vertical grid lines are at 0.200 intervals.


Are the units seconds or something else?

yes seconds. nothing fancy. This whole shot is 5s

What is the required accuracy of the timings of the synthetic signals?

The main point is that the rising edge of the blue pulse is within the on section of the black pulse and that the green signal is within the two.

Is rate accuracy important?

I.e. the system, and especially the top two pulse trains, appear to have a fixed period of 0.275; how closely does that need to be sythesized?

Could an alternate period be used e.g. 0.250 or 0.400, if the entire system were re-adjusted to it?

The top two pulses are that of a continuous overhead chain conveyor. they are fixed. Both sensors are detecting the same thing just one is a little later in a physical location.

Is intra-signal relative edge timing (pulse duration) important?

Is inter-signal relative edge timing important?

Rising edges, falling edges, or both?

as long as it mimics somewhere close to the screen dump. I am looking to build this program for a simulator to test the actual program.

The bottom green signal trace appears to have more variability, both in phasing relative to the more regular upper traces and in the presence or absence of 1s

It will do as sometimes the line will not have any products in the carrier.

Is there a model for this variability?
Would a model require a random number generator, or would a limited, pre-generated sequence of random numbers be adequate?

I didn't plan to get that technical I was going to put some contact on a timer to create the green pulse. change the timer value and see if it works ok.

Obviously, the model will be limited by the timing accuracy of the S7-1200, and the inter-scan timing, which can be variable. Repeating timers in the continuous main OB are non-deterministic and have some intrinsic noise; perhaps that could be useful for the rising edge of the bottom task.

Scheduled tasks (A-B terminology, sorry) would be one way to cut down on the inter-scan variability, but could a task be run at 1ms intervals if that was the accuracy requirement?

Pulse duration is another issue; I think monitoring the accumulated time, .ET, of a TON would be the best way to handle this.

... and don't call me Shirley (couldn't resist ).

the machine can be seen here,

https://www.youtube.com/watch?v=ISo5S_YEwDo

the trolley wheels (carriers) trigger the blue and black pulse the green pulse is triggered by the product.

I just want to emphasize this is a post to create a better test program, the actual process involving SHL bytes in a word to keep track I am ok with.

[hadwll]

Originally Posted by Peter Nachtwey

What about the phase relationship between the first and second pulse stream.


I don't think a PLC is the right tool for this job. I would try a Raspberry PI or similar.


I know that if I used my relatively expensive motion controller it would be done by now but you guys will waste much more time than the cost of the motion controller trying to make the PLC work.

If this is going to be a problem for the PLC I will test as best I can then finish off during commissioning

[drbitboy]

Originally Posted by hadwll

...
the machine can be seen here,

https://www.youtube.com/watch?v=ISo5S_YEwDo

the trolley wheels (carriers) trigger the blue and black pulse the green pulse is triggered by the product.

I just want to emphasize this is a post to create a better test program, the actual process involving SHL bytes in a word to keep track I am ok with.

Awesome. I went back and watched it at one-quarter speed.

With the lack of accuracy required I don't think this will be beyond what the S7-1200 can do. I would think sub-5ms 3-sigma accuracy is possible, which sounds like it's good enough. there could be a good fraction of that much noise in the chain sensors.

My approach would be

• A fixed rate event, say a ~275ms period, either an edge of a bit in the available clock memory byte or a scheduled task, to
  • put a 1 in the top (black) pulse output, and
  • trigger the reset and re-start of a TON timer,
    • The timer should have a .PV greater than the period; it will never complete because it's being used for its .ET
• Keep track of odd and even events e.g. toggle a bit at the start
• After that, keep track of the timer's .ET value to trigger the train of pulses
  • at 51ms > .ET > ~25ms put a 1 in the middle (blue) pulse output
  • at .ET > ~50ms put a 0 in the top (black) pulse output
  • at .ET > ~120ms put a 0 in the middle (blue) pulse output
  • for odd events, at .ET >~120ms+random, if the bottom (green) pulse output is 1, put a 0 in it
  • for even events, at .ET > ~200ms+random, choose whether to put a 1 in the bottom (green) pulse output

It may not need to be 275ms overall period; the clock memory byte has bits with rising edges at 200ms and 400ms intervals; so adjust the trigger points accordingly.


It may be worth caching the .ET value at the start of every scan, rather than reading from the TON block, where it may change throughout the scan.

[BryanG]

Using the equipment that you have. Set up a PTO Pulse train output at say 10 times the frequency of the fastest signal. Connect a piece of wire from the high speed output to a high speed counter input. Use the High Speed Counter to count the incoming pulses. Set the High Speed Counter interrupts at counts that give the ONs and OFFs that you need. It gets over any timing issues between pulse streams, uses the kit that you have and a programming language that you are used to. If you use the :P on the ONs and OFFs commands you write directly to the Outputs avoiding any delays in the process image that is used in the main cycle.

[L D[AR2,P#0.0]]

Set up three arrays containing 500 bools. Set the bools in the array to the values you want for the waveforms. In a timed interrupt OB (10ms), output the value from each array according to an index, then increment the index. Finish when the index gets to 500


Resultant trace (using plcsim)

[L D[AR2,P#0.0]]

Example code:

[hadwll]

Originally Posted by drbitboy

Awesome. I went back and watched it at one-quarter speed.

With the lack of accuracy required I don't think this will be beyond what the S7-1200 can do. I would think sub-5ms 3-sigma accuracy is possible, which sounds like it's good enough. there could be a good fraction of that much noise in the chain sensors.

My approach would be

• A fixed rate event, say a ~275ms period, either an edge of a bit in the available clock memory byte or a scheduled task, to
  • put a 1 in the top (black) pulse output, and
  • trigger the reset and re-start of a TON timer,
    • The timer should have a .PV greater than the period; it will never complete because it's being used for its .ET
• Keep track of odd and even events e.g. toggle a bit at the start
• After that, keep track of the timer's .ET value to trigger the train of pulses
  • at 51ms > .ET > ~25ms put a 1 in the middle (blue) pulse output
  • at .ET > ~50ms put a 0 in the top (black) pulse output
  • at .ET > ~120ms put a 0 in the middle (blue) pulse output
  • for odd events, at .ET >~120ms+random, if the bottom (green) pulse output is 1, put a 0 in it
  • for even events, at .ET > ~200ms+random, choose whether to put a 1 in the bottom (green) pulse output

It may not need to be 275ms overall period; the clock memory byte has bits with rising edges at 200ms and 400ms intervals; so adjust the trigger points accordingly.


It may be worth caching the .ET value at the start of every scan, rather than reading from the TON block, where it may change throughout the scan.

I am trying this solution.

I had a stab at this before work today, blue and black pulses are working well, green needs some more time spent to work out correctly.

Thanks for your input I will post the FBD when I have it sitting pretty.