Deadtime on a digital signal

And for the OP, use a FIFO. The OP requirement is you can press the button multiple times and repeat the pattern. Lare had it right, after only 28minutes. I am sure the homework assignment is complete by now.

Interesting. With a FIFO, the output would repeat every input rising or falling edge that gets stored in the FIFO, just N seconds later, right?

When I read the OP, I interpreted the goal such that, once the input rising edge was found, the program would ignore all other input activity until the output went off at the end of the 1s output hold.

Or maybe for the FIFO you meant to stop storing input changes until the end of the output response to the first input change?

Anyway, I have it working with two TONs, one rung to implement the delay, and one to implement the 1s output pulse. I have several more lines for debugging and viewing, and one other line to change the duration of the delay. Cf. here
 
Last edited:
What's the best way to do this?

I dunno about the best way, but assuming the homework assignment is complete, here is one way; the delayed output with the 1s hold will be T4:1/EN. The full solution is attached, for a ML1100.

Code:
     INPUT     T4:1/DN
--+---] [---+----]/[-------|TON            |--(EN)--
  |         |              |Timer      T4:0|
  | T4:0/EN |              |Time Base  0.01|--(DN)--
  +---] [---+              |Preset      500|
                           |Accum         0|


    T4:0/DN
------] [------------------|TON            |--(EN)-- <== OUTPUT
                           |Timer      T4:1|
                           |Time Base  0.01|--(DN)--
                           |Preset      100|
                           |Accum         0|
It seems to work (see the metoob in an earlier post), but my intuition says this is a brittle approach; as the saying goes, the best way to get the right answer is to post a wrong answer.

I had a XIO/NC on T4:1/DN on the T4:1 timer rung for a while, but eventually realized it was redundant.
 
Last edited:
I dunno about the best way, ... my intuition says this is a brittle approach

Ha, half a night's sleep and I wake up and finally see it: the INPUT should be replaced by a bit driven by the rising edge of that input i.e. a one-shot.

Otherwise, as diagrammed earlier, if INPUT never turns off, the cycle will repeat after T4:1/DN goes True/1.

d'Oh!
 
1. Help file
2. Ambiguity of OP
3. Assuming the homework is finished
1. Part of the reason ML are so cheap cheaper than the Logix5000 range is they have a different person (or at least a different amount of time allocated to) write the documentation. Check manual 1756-rm01, it has the obvious thing: a timing diagram!
2. Yes, I didn't realise but it does only say "the input may cycle on and off..." Keith asked the question, but the OP hasn't been back, probably after implementing a FIFO already.
3. Fair! Let's get both solutions working.
 
1. Part of the reason ML are so cheap cheaper than the Logix5000 range is they have a different person (or at least a different amount of time allocated to) write the documentation. Check manual 1756-rm01, it has the obvious thing: a timing diagram!
2. Yes, I didn't realise but it does only say "the input may cycle on and off..." Keith asked the question, but the OP hasn't been back, probably after implementing a FIFO already.
3. Fair! Let's get both solutions working.

2. Yes it's ambiguous; an ongoing trailing delay is equally reasonable
3. Yes! I am very interested in seeing a FIFO, especially the part where the delay is varied
3.1. My updated solution is attached (N.B. typos remain in comments); the guts are below.

Code:
     INPUT
------] [------------------|OSR                 |--------
                           |Storage bit  B3:0/14|
                           |Output bit   B3:0/13|


    B3:0/13    T4:1/DN
--+---] [---+----] [-------|TON                 |--(EN)--
  |         |              |Timer           T4:0|
  | T4:0/EN |              |Time Base       0.01|--(DN)--
  +---] [---+              |Preset           500|
                           |Accum              0|


    T4:0/DN
------] [------------------|TON                 |--(EN)-- <== Delayed output
                           |Timer           T4:1|
                           |Time Base       0.01|--(DN)--
                           |Preset           100|
                           |Accum              0|
 
Last edited:
3. Yes! I am very interested in seeing a FIFO, especially the part where the delay is varied


On FIFO block.


number of saved values would be time delay * TimeBase.
(1s timebase, 10s long delay = 10 registers
100ms timebase, 10s long = 100registers etc.)


Then pulse value to FIFO with timepulse (1s or 100mms) and FIFO output is your delayed input.





If there is no inbuild FIFO block on PLC, you can allways use several move blocks. (Maybe Array variables)
Then select correct array variable for output if you need varied delay.


For bool > FIFO register you need to conversion from bool to int.




Then it is only coding to real PLC
 
May I try:
If input is on,
Or's been on in the last PRE,
Turn on DONE (else off).
I tip my hat to you sir. The most simple and yet elegant description of a TOF I have ever come across, and in haiku form. Truly a thing of beauty!
 
Normally I wouldn't waste my time on this but it is after the super duper bowl.


A queue or FIFO is required.
I would want to know the maximum required delay.
I would like to know how fast the inputs are going on and off because that affects my sample time and the number of entries in the delay queue.
I would like to know how accurately, time wise, the original signal must be reproduced. That also affects the sample time.


I sell motion controllers that could do this easily, well almost.
First I can sample every 250 microsecond but if I use a BOOL for every 250 microsecond period in my delay queue I would use 80,000 BOOLs. That is too many especially if a BOOL is the same size as a DINT. I could reduce each entry to a bit access 80,000 bits. That would take 2500 DINTs which is doable but not practical. There is a better way.
Every time there is an off to on or on to off transition I could save away the 32 bit RTC in the queue. Now only transitions are saved and that could reduce the queue size immensely if the transition rate isn't too high. Now the question is "does the entry correspond to an of to on or on to off". I would use the LSB of the queue entry to indicate if the entry is an off to on or on to off transition. Yes, this messes up the time but the RTC has resolution much higher than the scan time ( 25ns ) the LSB will have no affect on the results.


Next there need to be a loop that samples the input every scan ( 250 microseconds ) and look for transitions on the input and when one is found it stores the RTC with the LSB possibly modified into the head of the queue. Then it must also check the entry at the tail of the queue to see if the RTC has reached or exceeded the store RTC entry in the queue plus the delay time. It the current RTC reaches or exceed the the delayed RTC + delay time then the output is set depending on the LSB of the delayed RTC entry. Note that this method lets the delay time be changed on-the-fly.


This would be very fast. It would be faster if it could be done in a FPGA.


If I were using a PLC I would use the same approach but there would be limitations on the resolution of the delay output.



This seems very obvious to me.


Jland fails. If you don't understand the problem you have little chance of knowing what to ask or solving it.


Timers accumulate error because they are not deterministic. Timers are OK if you don't need to keep track of time precisely.
 
Timers accumulate error because they are not deterministic.

Sometimes the same is true for RTCs, depending on how well the hardware designers do their job.

<Boring_story_mode>
My dad had a laptop with an 80386SX chip. He used it to sample data at 2Hz, and the 18.2Hz system clock was not accurate enough for one who had measured the heat rate of large steam turbines to 1/4% accuracy. So he tried POKEing and PEEKing at I/O-space addresses to read supposedly buffered 1.19MHz internal clock data. While the code succesfully polled clock data in a tight loop looking for half-second trigger counts, the system clock on the laptop fell behind the wall clock noticeably: each poll had a small probability of causing the clock to miss cycles from its source oscillator.

Macro Heisenberg, eh?
</Boring_story_mode>
 
Sometimes the same is true for RTCs, depending on how well the hardware designers do their job.

<Boring_story_mode>
My dad had a laptop with an 80386SX chip. He used it to sample data at 2Hz, and the 18.2Hz system clock was not accurate enough for one who had measured the heat rate of large steam turbines to 1/4% accuracy. So he tried POKEing and PEEKing at I/O-space addresses to read supposedly buffered 1.19MHz internal clock data. While the code succesfully polled clock data in a tight loop looking for half-second trigger counts, the system clock on the laptop fell behind the wall clock noticeably: each poll had a small probability of causing the clock to miss cycles from its source oscillator.

Macro Heisenberg, eh?
</Boring_story_mode>
You are talking about ancient technology. Now the CPU chips have a counter that counts clock cycles while the chip is on. It keeps counting and rolls There is no need for extra hardware unless there is need for TOD features.

Polling at that rate was not a good idea. I would have used a high priority interrupt triggered by a timer/counter. The software in the interrupt would need to be very efficient. I believe there was an extra counter/time channel that could have been used for this.

This is also why I don't like Modbus RTU. The beginning and ending of packets is based on character timing and the 18.2 Hz timer was not fast enough. Few people implement Modbus RTU correctly because they didn't use the extra counter/timer channel for faster interrupts. You don't know how many hours I have spent telling people that the implementation of Modbus RTU they are using does not meet specifications and no, I will not modify ( screw up ) my code just to work with someone else's poor implementation of Modbus RTU. Tell the other guys to meet the spec.
I used DMA on our old RMC100s to make sure there were no gaps between characters when sending and no missed characters when receiving no matter what the bit rate was.
 
I went to implement this in CODESYS but couldn't find a FIFO block that I liked, so I went ahead and implemented a digital delay function as a FIFO circular buffer instead.

The FIFO circular buffer is a bit different to the Rockwell FIFO (is the term non-circular buffer?), in that it doesn't shift every element in the entire buffer along one each time it wants to add something. For larger arrays, this is more efficient.

This function will also be easily turned into an Analog delay, should you need one.

Critique welcome.

Screen Shot 2020-02-03 at 18.59.01.png Screen Shot 2020-02-03 at 19.07.52.png
 

Attachments

  • DigitalDelayAustralIan.project.zip
    122.7 KB · Views: 2
Last edited:
Never mind TOF.... MCRs are the devil squared......
have got lost in the middle of those damn things when working with
unfamiliar ladder...
That should be on!!!!
Why isn't that math instruction working ?!!?!?!
 
Originally posted by AustralIan:

For larger arrays, this is more efficient.
[\quote]

Its more efficient for smaller arrays too.

I haven't used a Rockwell FIFO in years. I always use a circular queue for anything a FIFO or LIFO would be used for. They are great for general tracking as well.

Keith
 
MCRs are the devil squared......

(1.) How MCR is implemented

| IN1 |
+-] [-----(MCR)-+
| |
| IN2 OUT1|
+-] [-------( )-+
| |
| IN3 OUT2|
+-] [-------( )-+
| |
+---------(MCR)-+
| |
| IN4 OUT3|
+-] [-------( )-+
| |



(2.) How MCR could have been implemented

| IN1 |
+-] [-------(MCR)-+
| | |
| +-----------+ |
| | |
| | IN2 OUT1|
| +-] [-------( )-+
| | |
| | IN3 OUT2|
| +-] [-------( )-+
| |
| |
| IN4 OUT3|
+---] [-------( )-+
| |


Note that the second MCR leg would have changed colour with the state of the MCR

(3.) How MCR should be implemented in future, based on our experience of (1.)

Release Notes:
The MCR instruction has been deprecated in this version. Please make sure you refactor your code like a normal human being. We are also releasing a new minor version of all older firmware and software, removing the ability to use this function. We will be removing from our download area any previous versions that once supported this function. Also, searching for MCR in the help will bring up the number for a 24hr coffee delivery service. The coffee is terrible, but clearly you're not thinking clearly and you might be in front of a machine!
 

Similar Topics

I am trying to impliment some pH control logic on a wastewater treatment system. We are useing 93% sulfuric acid and 57% magnesium hydroxide as...
Replies
5
Views
3,011
I want to study the PIDAT instruction autotuning in Omron CJ1M PLC. For that I want to simulate a process with deadtime and first order lag...
Replies
0
Views
4,151
Question to anyone with ideas about my thoughts on upgrading a very vintage timer, which is being used to switch between 2 5hp domestic water...
Replies
14
Views
366
I have a PLC type PM856 from ABB with some I/O modules and I get an error from the Digital Inputs model type DI801. The unit status shows error...
Replies
0
Views
246
I am monitoring two BMXDDO3202K digital outputs for their behaviour, they are each for opening and closing, and so the on time affects how far the...
Replies
1
Views
273
Back
Top Bottom