That lets me carry on testing
1 Like
Ok - it seems to do the job
One other thing apart from reset - when manually slowly testing, i.e. sending 3 messages - 1st one goes thru - other 2 are queued
I'm manually injecting into the release node but when I see the queue goto zero, sometimes I forget to press again
And then of course, at the start of my next test - the 1st message is unexpectedly queued
Could you add some visual clue as to the difference between - next msg will go straight thru and next msg will be queued.
Just for us older people who can't remember how many times they've pressed a button
[edit}I'd suggest green for good to go and maybe keep it at yellow until semaphore reset?
1 Like
Agreed!
I’ll add a global stat, to state if release has not been called (either manually or via fs) to let us know if the lock is currently engaged!
I'd suggest green for good to go and maybe keep it at yellow until semaphore reset?
1 Like
All testing passed so going to fully integrate it into my project
1 Like
Im working on the enhancements now...
1 Like
I did try bodging in a reset but it didn't work so glad a proper solution is on the way
The smp_reset property will be sent to the release node.
and if this property is true
Will dispose of and clear all awaiting messages across all take nodes.
I have chosen the magic prefix of smp_ so it doesn't affect any other nodes in the flow (well should't do, I cant control what others around the world do in their Nodes 
)
1 Like
Decided to have a pay with setting a fail-safe time
Set it using an inject (cause I have another inject to put it back to 0)
Semaphore take node shows LFS 5000
But after 1st message has gone thru - it changes back to disabled - which was unexpected
Why doesn't it keep using the FS time set?
The magic property is smp_failsafeTimeout 
and will be applied once a message with this property passes through, if the next message to pass, does not have this property, it will use whatever is setup in the Node it's self
its like an override for the message currently holding the lock closed
Don't think I'm quite on the same page yet
So, what I'm after is to inject a failsafe timeout to override the manual timeout setting.
And for this setting to be applied for ALL currently queued and future messages until I change it again
Are you saying that I need to use smp_failsafeTimeout?
This is all quite confusing
Think of it this way...
The fail-safe is applied per message, and it governs how long a message has, to hit the release node.
So if it doesn't hit the release node by the fail-safe time - the next message will allow to pass.
But if you need to give more time to a message - (example somewhere in your flow it suddenly needs more time for a specific message to finish), you can set a new fail-safe time (with the FS Reset Node)
Both FS Reset and the Take node will use the fail safe default (set in the node its self).
Example you can send 2 messages where one has 10s to complete, and the other has 20s to complete
node.send({..., `smp_failsafeTimeout`:10000}) /* Will have 10s to complete once its allowed through */
node.send({..., `smp_failsafeTimeout`:20000}) /* Will have 20s to complete once its allowed through */
And each of these can be changed (whilst it's in transit to the Release node via the FS Reset Node)
if you don't specify smp_failsafeTimeout it will use what is setup in the Node
1 Like
After a good nights sleep, I realise that most of this is standard stuff.
Manual setting in the node is overridden on a per message basis by msg.smp_failsafeTimeout
But IMHO the msg.fail-safe action is non-standard and confusing
Your right to suggest this.
I'd forgotten that I actually use that technique in other flows i.e.
At the moment, I'm going to stick with @marcus-j-davies nodes as they do the same job but with no need for a return wire.*
And they avoid the delay problem you can get with the 1st message from time to time.
*But, the NR way is to NOT have invisible wires so I've added this disabled one to keep to the proper spirit
or maybe a disabled dummy link would be better?
with explanation in node name
I may be over-thinking this now
3 Likes
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
