CAI_Support
Senior Member
Current shipping firmware should allow user to have non-blocking delay on IP, at same time to get IP current state. In your example, VAR1 could have different value from IP1[1000] during delay.
Non-Blocking Delay on IP2 broken v03.02.17e Bug?
- Thread starter TJF1960
- Start date
CAI_Support said:
I have not tested my code, but I think your diagram is wrong.
See the XOR? After detecting a "change of state" it then XORs the "last" state with the "current" state. If unchanged, no action. That would achieve the same filtering function the current code does, except on both normally high and normally low inputs, yes??
CAI_Support
Senior Member
rossw said:
Our original design considered the need to filter out the small glitches, so that we use the term "non-blocking delay" on TTL input to handle it. Tim needs to have both direction filtering in the same program. His PLC code executed in a few different version, including 3.02.17e and 3.02.17f. Version 3.02.17e is same as two years on the TTL input logic. The positive going pulse portion of his code working perfectly. The problem is in his PLC code negative going pulse filtering. In our original design, user could configure the Input invert to work on negative going pulses. However, Tim needs both positive going and negative going. So our proposal is to add a switch command, so that PLC programmer knowing which section he want to detect, then he can switch dynamically in the PLC code.
You are all very smart persons, I am sure what you proposed must have a lot of deep thinking behind it. We want to make sure not miss any of your good ideas to make this working better. How to make this work more elegant.
High-level and highly-specific commands are useful if not essential for some things. However the more specific they become the less widely-useful they become (by their very definition).
In my near enough to 40 years of electronics and programmable devices experiences, lower-level "building blocks" have proven to be more useful (but not necessarily more elegant).
I think I made a comment quite some time ago about adding an opcode for "edge" detection. This primative would be very handy for a great many real-time things. Combined with an ability to read the number of ticks since a change lends itself to a fairly elegant, universal solution.
Last year, I wrote code to permit bidirectional serial communications over a singe wire between multiple devices (one master and an arbitary number of slaves, master sends commands, the addressed slave replies). This required quite tight timing and both rising and falling edge detection. Although you specify the minimum timing to be 100ms, I had it working significantly faster than that - but with other things stealing CPU time, I've had to slow it down to make it reliable.
Edge-detect and time-since-event would have been really handy!
In my near enough to 40 years of electronics and programmable devices experiences, lower-level "building blocks" have proven to be more useful (but not necessarily more elegant).
I think I made a comment quite some time ago about adding an opcode for "edge" detection. This primative would be very handy for a great many real-time things. Combined with an ability to read the number of ticks since a change lends itself to a fairly elegant, universal solution.
Last year, I wrote code to permit bidirectional serial communications over a singe wire between multiple devices (one master and an arbitary number of slaves, master sends commands, the addressed slave replies). This required quite tight timing and both rising and falling edge detection. Although you specify the minimum timing to be 100ms, I had it working significantly faster than that - but with other things stealing CPU time, I've had to slow it down to make it reliable.
Edge-detect and time-since-event would have been really handy!
CAI_Support
Senior Member
Ross,
You and az1324 are advanced engineers, from postings both of you did, we made great improvement to the product features. I am sure we will careful consider all your suggestions. Once engineers understand your suggestions, we can implemented for you. For this particular requirement from Tim, we want to find a way without impact existing users, also can handle both direction going pulses.
Edge detection is a good idea. How could that be used to help Tim's case, also without impacting current users, that is not very clear. If that is not feasible, we can introduce totally new command to read same TTL input and using different logic more versatile for all purposes.
You are correct 100ms is not the smallest time for reading TTL input, actually, each time PLC reference to TTL value, it will read it, if it changed from last time, it will record that change. So if you want to do communication, you first have a long pulse, so that if your PLC code take one whole second to loop through, this long pulse will make sure you will run into it. Then you can call the communication subroutine, where you can just beat up the IP line for state change. Other interrupt, like network, could steal CPU from your routine.
Would you like to suggestion a totally new command or we just let programmer to change the 0V->5V detection to 5V->0V detection?
You and az1324 are advanced engineers, from postings both of you did, we made great improvement to the product features. I am sure we will careful consider all your suggestions. Once engineers understand your suggestions, we can implemented for you. For this particular requirement from Tim, we want to find a way without impact existing users, also can handle both direction going pulses.
Edge detection is a good idea. How could that be used to help Tim's case, also without impacting current users, that is not very clear. If that is not feasible, we can introduce totally new command to read same TTL input and using different logic more versatile for all purposes.
You are correct 100ms is not the smallest time for reading TTL input, actually, each time PLC reference to TTL value, it will read it, if it changed from last time, it will record that change. So if you want to do communication, you first have a long pulse, so that if your PLC code take one whole second to loop through, this long pulse will make sure you will run into it. Then you can call the communication subroutine, where you can just beat up the IP line for state change. Other interrupt, like network, could steal CPU from your routine.
Would you like to suggestion a totally new command or we just let programmer to change the 0V->5V detection to 5V->0V detection?
CAI_Support said:
My serial routine uses an unusual technique. Rather than a normal "start bit", I send a split-start which is used to both synchronise the start of the transmission and to determine the communication speed. So yes, there is a period long enough to get sorted out, and it's been working quite reliably for 9 months now.
The argument of not breaking existing code is a strong argument.
I would personally be in favor of introducing an additional opcode, for example, "edge". It should take at least one optional operand - it would be great to be able to select rising, falling or either.
I think there also needs to be some clear and detailed documentation of how the (previously titled 'non-blocking-delay') actually works, including perhaps a change of name to something that more accurately describes it. (you used the term "filter" earlier - if its function is indeed to filter out short-duration spikes, then referring to it as a "filter" may well be more appropriate!).
There is also a lot of merit in letting the programmer access the elapsed time since the last state-change. That gives us great flexibility.
CAI_Support
Senior Member
Could you please elaborate more on this "edge" command, how would that help Tim's case and also add capabilities for other use?
For example,
IPEDGE a b c
where a is TTL input, b is last state change was rising edge, c is where to store the time since it happened.
a can be 1 to 8 for TTL input number
b has value: if last state change was rising edge, using 0, falling edge, using 1, if for both, using 2,
c can be VAR or RAM, If the PLC code specified rising edge, but last change was falling edge, c == 0.
Also, we can set zero bit in addition, for result is false, if so decided.
Would this be any useful for Tim or other purpose?
For example,
IPEDGE a b c
where a is TTL input, b is last state change was rising edge, c is where to store the time since it happened.
a can be 1 to 8 for TTL input number
b has value: if last state change was rising edge, using 0, falling edge, using 1, if for both, using 2,
c can be VAR or RAM, If the PLC code specified rising edge, but last change was falling edge, c == 0.
Also, we can set zero bit in addition, for result is false, if so decided.
Would this be any useful for Tim or other purpose?
I know this is Tim's thread, but we care about general case. Sorry, Tim. :blush: Anything that helps everyone helps Tim.
I think what is desired:
1. Allow access to the timestamps
2. Allow the user to set whether the timestamp is updated on rising/falling/both
So for example
IPEDGE a b
a = input #
b = 0,1,2 (0=update timestamp only on falling edge, 1=update timestamp only on rising edge, 2=update timestamp on both rising/falling)
IPx{y} return 0 if timestamp is less than y milliseconds ago, else 1
IPTS a b
a = destination where to copy the TS (VAR, RAM)
b = input #
I think what is desired:
1. Allow access to the timestamps
2. Allow the user to set whether the timestamp is updated on rising/falling/both
So for example
IPEDGE a b
a = input #
b = 0,1,2 (0=update timestamp only on falling edge, 1=update timestamp only on rising edge, 2=update timestamp on both rising/falling)
IPx{y} return 0 if timestamp is less than y milliseconds ago, else 1
IPTS a b
a = destination where to copy the TS (VAR, RAM)
b = input #
CAI_Support
Senior Member
Az1324,
Thanks for your suggestions. Please clarify that:
1) IPEDGE a b
is to set the how internally recording the time stamp;
2) IPx{y}
is reading the IPx logic state based on 1)
3) IPTS a b
is to read the timestamp of last change.
Please note internally, we record IPx state change all the time, so that timestamp is last actual TTL input change, it could be rising or falling. Are you saying we need to keep the previous state-change timestamp all the time? Otherwise, we can tell the last falling time, if the last state change was falling.
Thanks for your suggestions. Please clarify that:
1) IPEDGE a b
is to set the how internally recording the time stamp;
2) IPx{y}
is reading the IPx logic state based on 1)
3) IPTS a b
is to read the timestamp of last change.
Please note internally, we record IPx state change all the time, so that timestamp is last actual TTL input change, it could be rising or falling. Are you saying we need to keep the previous state-change timestamp all the time? Otherwise, we can tell the last falling time, if the last state change was falling.
No IPx{y} is only reading the timestamp, whether it has changed within y milliseconds, regardless of state. But that one is optional since it could be done with two lines of code using #3. Although #3 should probably return ticks ago or the smallest unit of time available.
Just like LED the default for IPEDGE is 2. But if the user sets it to something else then you only update the timestamp on those conditions. Yes, changing the setting will affect how non-blocking delay operation works but just make a note of it and let the user decide what to do.
Just like LED the default for IPEDGE is 2. But if the user sets it to something else then you only update the timestamp on those conditions. Yes, changing the setting will affect how non-blocking delay operation works but just make a note of it and let the user decide what to do.
CAI_Support
Senior Member
Thanks, so IPx{y} can be skipped. The less new command the better. I remembered my physics professor taught me many many years ago:
simply beautiful.
If we can make it simple, we don't want to make it complex.
Do you have any application for these added commands that we can imagine the use of them? Especially how they will help Tim's case.
Ross, if you could please also contribute what you think and any change that can be better.
simply beautiful.
If we can make it simple, we don't want to make it complex.
Do you have any application for these added commands that we can imagine the use of them? Especially how they will help Tim's case.
Ross, if you could please also contribute what you think and any change that can be better.
CAI_Support
Senior Member
But the guaranteed the minimum pulse recorded is 100ms. In real use, it can be faster than that, but if all things busy, it will slow down to 100ms. Would that be fast enough to talk to sensor? To talk to sensor, we will need to implement something more accurate for capturing the phase change using timers.
If you have some sensor in your mind, we could add support for them in the firmware.
How the IPEDGE help Tim's case? We still want to resolve that for Tim. One way to do that is to add another 8 IO IDs that is for negative going. So that current IPx[] still work with low to high pulse, IPRx[] will work for high to low pulse. User don't have to switch anything, both of them work at the same time.
Would that make your communication task easier? You count 0->1 pulse using IPx[]
then 1->0 going pulse using IPRx[]
If you have some sensor in your mind, we could add support for them in the firmware.
How the IPEDGE help Tim's case? We still want to resolve that for Tim. One way to do that is to add another 8 IO IDs that is for negative going. So that current IPx[] still work with low to high pulse, IPRx[] will work for high to low pulse. User don't have to switch anything, both of them work at the same time.
Would that make your communication task easier? You count 0->1 pulse using IPx[]
then 1->0 going pulse using IPRx[]
I thought you already resolved that by implementing IPINV command to invert inputs.
Tim can do something like:
MYSUB:
TSTEQ IP1{30000} 1 //did IP1 last change more than 30 seconds ago
GOTO PULSE //yes, long pulse detected
SET RAM2 0 //no, reset flag
RET //we have no long pulses, do nothing
PULSE:
TSTEQ RAM2 1 //did we already service this pulse?
RET //yes, return
SET RAM2 1 //Set flag that we are servicing this pulse
TSTNE IP1 1 //is input 1 currently high
GOTO IS_LOW //no it is low
SET OP1 1 //Long high pulse detected. Do what we want.
RET
IS_LOW:
SET OP1 0 //Long low pulse detected. Do what we want.
RET
IP timestamps can be updated during tick interrupt for best accuracy.
Some things require calculations that use the actual length of the pulse in ticks.
Tim can do something like:
MYSUB:
TSTEQ IP1{30000} 1 //did IP1 last change more than 30 seconds ago
GOTO PULSE //yes, long pulse detected
SET RAM2 0 //no, reset flag
RET //we have no long pulses, do nothing
PULSE:
TSTEQ RAM2 1 //did we already service this pulse?
RET //yes, return
SET RAM2 1 //Set flag that we are servicing this pulse
TSTNE IP1 1 //is input 1 currently high
GOTO IS_LOW //no it is low
SET OP1 1 //Long high pulse detected. Do what we want.
RET
IS_LOW:
SET OP1 0 //Long low pulse detected. Do what we want.
RET
IP timestamps can be updated during tick interrupt for best accuracy.
Some things require calculations that use the actual length of the pulse in ticks.
