Hi
Thanks Martin for the reply and I shall check this out. I came across an issue wherein supposed I give the same input port A4 two high pulse trigger before the first cycle gets complete. The second one’s input is not taken.
Is there any simple get around to this ?
Implementing a non blocking delay
-
mvictor
- Posts: 28
- http://meble-kuchenne.info.pl
- Joined: Thu Aug 25, 2022 7:46 am
- Has thanked: 3 times
- Been thanked: 1 time
-
medelec35
- Valued Contributor
- Posts: 2247
- Joined: Wed Dec 02, 2020 11:07 pm
- Has thanked: 690 times
- Been thanked: 761 times
Re: Implementing a non blocking delay
Chipfryer21 is doing a great job in helping, I do not want to step on his toes.
My sole intention is getting the equivalent to timer interrupt simulation working the same as on embedded hardware for anyone that requires that option.
If Chipfryer27 requires additional help then I will see what I can do to help.
My sole intention is getting the equivalent to timer interrupt simulation working the same as on embedded hardware for anyone that requires that option.
If Chipfryer27 requires additional help then I will see what I can do to help.
Martin
-
chipfryer27
- Valued Contributor
- Posts: 1877
- Joined: Thu Dec 03, 2020 10:57 am
- Has thanked: 409 times
- Been thanked: 633 times
Re: Implementing a non blocking delay
Hi
Welcome any and all suggestions especially as the target chip has limited RAM and pins are aleady allocated. I seem to be in an endless loop regarding ideas, based around either CB or a shift register. I discounted DSP as I thought (possibly wrongly) that the chip would struggle?
Regards
Feet well hiddenI do not want to step on his toes.
Welcome any and all suggestions especially as the target chip has limited RAM and pins are aleady allocated. I seem to be in an endless loop regarding ideas, based around either CB or a shift register. I discounted DSP as I thought (possibly wrongly) that the chip would struggle?
Regards
-
medelec35
- Valued Contributor
- Posts: 2247
- Joined: Wed Dec 02, 2020 11:07 pm
- Has thanked: 690 times
- Been thanked: 761 times
Re: Implementing a non blocking delay
mvictor
There are a lot of posts to catch up on.
Rather than doing that if there can be a full breakdown of what you want the hardware to then I will take a look into it.
Martin
-
medelec35
- Valued Contributor
- Posts: 2247
- Joined: Wed Dec 02, 2020 11:07 pm
- Has thanked: 690 times
- Been thanked: 761 times
Re: Implementing a non blocking delay
Hi Thank you for you breakdown:
It can be tweaked where necessary.
I'm not sure how long you wanted the solenoids on for.
Just made up a number e.g.10 Seconds
Hi Have quickly put something together that should simulate.mvictor wrote: ↑Mon Jan 26, 2026 12:57 pmSo here’s what I’m trying to do:
I have a camera which will grade objects. The camera is giving signal to a PLC which has mechanical relay outputs. I have to reject 3 grades.
My program will control 3 push pull solenoids of 12V. They are connected to 3 ports on B. It goes as follows as my PCB is that way.
A4 high trigger will pulse B5 after 3 sec (reject station 1)
A0 high trigger will pulse B6 after 4 sec (reject station 2)
A1 high trigger will pulse B7 after 5 sec (reject station 3)
(The seconds here is for example).
The reason I need this is, there is a conveyor belt which has pockets. Each pocket is 1s apart and the speed of the conveyor is fixed. So each reject station is 3, 4 and 5 second apart.
Chipfryer’s program did the above but the challenge I face is, supposed there are two objects in line of the same grade, say A4’s. Since the first case 3 second is not complete, the second one’s input is ignored. But it works well for different grades.
This is the challenge.
It can be tweaked where necessary.
I'm not sure how long you wanted the solenoids on for.
Just made up a number e.g.10 Seconds
- Attachments
-
- Thermaltimingjan_Example v3.fcfx
- (27.42 KiB) Downloaded 7 times
Martin
-
chipfryer27
- Valued Contributor
- Posts: 1877
- Joined: Thu Dec 03, 2020 10:57 am
- Has thanked: 409 times
- Been thanked: 633 times
Re: Implementing a non blocking delay
Hi Martin
I thought on using the DSP components.
Input switches populate an array, delay array, with the output used to control LEDs.
Tested using a single byte which didn't eat up much RAM but faced a bug with array (now fixed). Not had time to revisit yet. However if the DSP is to be used he would need to upgrade to latest release unless he has a DSP license pack for v9.
My thoughts about the DSP (might be wrong) was that if the switch was on for x-mS, the the output, after delay would be on for the same time, assuming sampling rate permitted.
Regards
I thought on using the DSP components.
Input switches populate an array, delay array, with the output used to control LEDs.
Tested using a single byte which didn't eat up much RAM but faced a bug with array (now fixed). Not had time to revisit yet. However if the DSP is to be used he would need to upgrade to latest release unless he has a DSP license pack for v9.
My thoughts about the DSP (might be wrong) was that if the switch was on for x-mS, the the output, after delay would be on for the same time, assuming sampling rate permitted.
Regards
-
mnfisher
- Valued Contributor
- Posts: 1824
- Joined: Wed Dec 09, 2020 9:37 pm
- Has thanked: 153 times
- Been thanked: 861 times
Re: Implementing a non blocking delay
A couple of other ideas.... To handle the multiple 'item' issue.
Both in 'idea' form...
Represent the conveyor as a series of slots - where 0 is okay and one is 'faulty' - this could be a circular buffer (or an array of bytes / bits) - this needs to 'move' in sync with the conveyor.
When a high pulse is received write a '1' to the output buffer (or a series of 1s -depending on the time interval required for the output)
At each time 'interval' - shift the representation of the conveyor 'right' one - and if there is a 1 in the buffer turn on the reject solenoid.
Or...
On a high input - write the current time to a queue (this is variable length list of items - first in first out (FIFO)) (represented by an array or a circular buffer)
Every millisecond (or other time period) compare the current time against the time of the first item in the queue - if it is >(time + delay + output time reqd) - turn off the output and discard the queue item.
If it is > time + delay turn on the output.
Martin
Both in 'idea' form...
Represent the conveyor as a series of slots - where 0 is okay and one is 'faulty' - this could be a circular buffer (or an array of bytes / bits) - this needs to 'move' in sync with the conveyor.
When a high pulse is received write a '1' to the output buffer (or a series of 1s -depending on the time interval required for the output)
At each time 'interval' - shift the representation of the conveyor 'right' one - and if there is a 1 in the buffer turn on the reject solenoid.
Or...
On a high input - write the current time to a queue (this is variable length list of items - first in first out (FIFO)) (represented by an array or a circular buffer)
Every millisecond (or other time period) compare the current time against the time of the first item in the queue - if it is >(time + delay + output time reqd) - turn off the output and discard the queue item.
If it is > time + delay turn on the output.
Martin
-
chipfryer27
- Valued Contributor
- Posts: 1877
- Joined: Thu Dec 03, 2020 10:57 am
- Has thanked: 409 times
- Been thanked: 633 times
Re: Implementing a non blocking delay
Hi guys
I think a potential issue for many approaches is the chip itself, having by modern standards not a lot of memory. Offhand 384 bytes?? which I think would be consumed quite quickly by any large array or buffer. This may mean a comparison approach is better suited based on a counter value.
I do have one of the chips, but my multi-programmer is in my evil-lab (aka ice station zebra at present) but I will grab and test once I defrost myself after entry.
Well if still needed.
Following on from another post, that scope' would generate some pulses of 300mS duration and time how long they took to appear etc. Well many of my scopes and analysers can do that too, but it is my albeit rocky justification for a new purchase
Regards
I think a potential issue for many approaches is the chip itself, having by modern standards not a lot of memory. Offhand 384 bytes?? which I think would be consumed quite quickly by any large array or buffer. This may mean a comparison approach is better suited based on a counter value.
I do have one of the chips, but my multi-programmer is in my evil-lab (aka ice station zebra at present) but I will grab and test once I defrost myself after entry.
Well if still needed.
Following on from another post, that scope' would generate some pulses of 300mS duration and time how long they took to appear etc. Well many of my scopes and analysers can do that too, but it is my albeit rocky justification for a new purchase
Regards
-
mnfisher
- Valued Contributor
- Posts: 1824
- Joined: Wed Dec 09, 2020 9:37 pm
- Has thanked: 153 times
- Been thanked: 861 times
Re: Implementing a non blocking delay
I did a simulation only version of the 'slots' approach....
The only v11 (maybe) thing is LED::SetState() - Can replace with If(value) LedOn else LedOff.
As it's simulation only - memory not an issue
In my crude 'conveyor belt' animation it takes an item about 30s to get from 'button' to 'reject' (LED) - the queue approach would likely use less memory (depending on number of items on the belt)
I've also just put the 'reject' LED on for 1s (the limit of timer accuracy in sim) - but on hardware could do SolenoidOn(3s) or whatever.
There is approximately 30s between pressing the button and the item reaching the reject chute - though this is easy to adjust (there is a constant)
Multiple buttons could use multiple bits (rather than multiple arrays!) The conveyor (a string here) - doesn't necessarily bear any resemblance to the real world - for illustrative purposes only!
Simulation is a bit 'wobbly' at the moment - with long 'delays' before movement etc, buttons not responding. I'm not sure if a delay in the loop in main helps or not...
Scope - the thought of getting a second has crossed my mind - in case the first goes wrong....
Martin
The only v11 (maybe) thing is LED::SetState() - Can replace with If(value) LedOn else LedOff.
As it's simulation only - memory not an issue
I've also just put the 'reject' LED on for 1s (the limit of timer accuracy in sim) - but on hardware could do SolenoidOn(3s) or whatever.
There is approximately 30s between pressing the button and the item reaching the reject chute - though this is easy to adjust (there is a constant)
Multiple buttons could use multiple bits (rather than multiple arrays!) The conveyor (a string here) - doesn't necessarily bear any resemblance to the real world - for illustrative purposes only!
Simulation is a bit 'wobbly' at the moment - with long 'delays' before movement etc, buttons not responding. I'm not sure if a delay in the loop in main helps or not...
Scope - the thought of getting a second has crossed my mind - in case the first goes wrong....
Martin
- Attachments
-
- conveyor.fcpcd
- (17.19 KiB) Downloaded 3 times