Page 7 of 8

Re: Implementing a non blocking delay

Posted: Mon Jan 26, 2026 12:14 pm
by mvictor
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 ?

Re: Implementing a non blocking delay

Posted: Mon Jan 26, 2026 12:55 pm
by medelec35
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.

Re: Implementing a non blocking delay

Posted: Mon Jan 26, 2026 12:57 pm
by mvictor
Hey

Actually he too needed suggestion as previously posted. He wasn’t too sure whether CB is the best idea so he was waiting for better suggestions.

Regards

Re: Implementing a non blocking delay

Posted: Mon Jan 26, 2026 3:34 pm
by chipfryer27
Hi
I do not want to step on his toes.
Feet well hidden :lol:

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

Re: Implementing a non blocking delay

Posted: Tue Jan 27, 2026 10:50 am
by medelec35
:lol:
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.

Re: Implementing a non blocking delay

Posted: Wed Jan 28, 2026 12:55 am
by medelec35
Hi Thank you for you breakdown:
mvictor wrote:
Mon Jan 26, 2026 12:57 pm
So 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.
Hi Have quickly put something together that should simulate.
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

Re: Implementing a non blocking delay

Posted: Wed Jan 28, 2026 3:20 am
by chipfryer27
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

Re: Implementing a non blocking delay

Posted: Wed Jan 28, 2026 7:05 am
by mnfisher
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

Re: Implementing a non blocking delay

Posted: Wed Jan 28, 2026 10:23 am
by chipfryer27
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 :D

Regards

Re: Implementing a non blocking delay

Posted: Wed Jan 28, 2026 11:43 am
by mnfisher
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