Order of executed nodes in flow

[Francois Vander Linden]

If a node has several output nodes, which output node is going to be "executed" first ? My guess is that it's in the order of creation but maybe I'm wrong. Maybe it would be interesting to have the ability to (optionally) display a "node number execution order" next to a node ? that way, even if you move nodes around you know in which order it will be executed ...

[Nick O'Leary]

Strictly speaking, if a flow branches you cannot make any assumptions about the relative order the two branches will be executed. That is a runtime implementation detail that could change.

The current implementation will pass messages down the wires in the order they were added, in a depth first order.

On Tue, 17 Oct 2017, 18:59 Francois Vander Linden, <fvli...@osmotiq.com> wrote:

If a node has several output nodes, which output node is going to be "executed" first ? My guess is that it's in the order of creation but maybe I'm wrong. Maybe it would be interesting to have the ability to (optionally) display a "node number execution order" next to a node ? that way, even if you move nodes around you know in which order it will be executed ...

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.
To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/f7a9375e-524c-46ae-b107-b8a6e487f93e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Francois Vander Linden]

Thanks for the answer Nick. I understand and respect the current "way of things". But once you've decided which order it will be (as it seems to be the case ... even for now), it might be an interesting idea to display this order in a way or another....

[Nick O'Leary]

> once you've decided which order it will be

This isn't a question of me deciding.

In the future the message passing code will be a pluggable component of the runtime - anyone could write a custom message router. The order will not be fixed.

Nick

To unsubscribe from this group and stop receiving emails from it, send an email to node-red+unsubscribe@googlegroups.com.

To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.

To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/9c69f9c9-3f02-4cb1-9803-0ce7496adec9%40googlegroups.com.

[Simon H]

Hi Franccois; 

also be aware that one of the msgs output will be the original msg, and the others will be clones, in the current implementation.  

To CONTROL the output order, and only send non-clones, I create a function node and call node.send() separately for each output.  In the CURRENT implementation, this allows execution order to be controlled and the msg sent to always be the original, at least until one of the messages hits a node which produces an async output.

This allows naughty things like sending the msg to a chain which modifies it, then sending the modified msg down another chain - not recommended but possible (in the current back-end implementation).

Simon

[DoNcK]

Hi Nick,

Le mardi 17 octobre 2017 21:28:15 UTC+2, Nick O'Leary a écrit :

In the future the message passing code will be a pluggable component of the runtime - anyone could write a custom message router.

Oh nice !

The order will not be fixed.

I've being using Noder-Red for a few years, and everytime I introduce it to somebody, I get the same impression that users are expecting the order of execution to be predictable from the shape of their flow. (Nah... this one is not from Sting !)
IMO this should be the default beahaviour (unless you write a custom message router for some advanced stuff).


Here is my proposition to adress this expectation :

In most countries, we write from left to right and top do bottom. I think a nice way of ordering the execution of multiple outpout nodes would be to follow this convention. To me it is pretty clear intuitive ! To swap the order of execution of two blocks, you just swap their position. There is also no need for deleting+recreating links between nodes when you want to change the order of execution which I found myself and others doing, mostly to get the debug messages after or before the execution of some stuffs. (I consider doing this as a bad practice as it is absolutely not visible in the flow, but I could'nt find anything more conveninent)

My 2 cents

DoNcK

[Michael Hogan]

It would be very cool to make a function-block language that resembles Node Red, but which is an imperative, scan-based language, rather than a message based language.

The IEC61131-3 function block language is a good example. There is also an IEC61131-3 language called SFC (sequential function charts) that is a flow-chart-like language, and 61131 defines a standard for ladder logic as well. It also defines a Pascal-like language called structured text (ST) that is probably not worth bothering with .. there are much better embedded scripting languages available that could fill its role.

At any rate, the development of a graphical language based on these models is not particularly difficult. I have a shell of a JS based, SFC-like language for batch control development that conforms to the S88 batch standard. It's relatively easy to write generators that will produce programs in these languages with relatively brief textual scripts, and fairly easy to render the results graphically using JS's reflection capabilities (it requires a bit of forethought in the design of the code for the language, but nothing overwhelming).

The hard part is making a good gui for graphical programming. There are some libraries out there that help, but it's still a ton of work to make a wysiwyg editor that is reasonable. In my view, this is the most impressive technical aspect of NR .. and it probably accounts for nearly all of its popularity, which in turn accounts for its continued progress.