Trying to run some python scripts with the Executor node here. It looks like the Output and Error output pins behave in an inconsistent way.
You’ll find a little POC attached. It’s just a silly Python script that writes two strings to the console and finally raises an exception. The vvvv patch simply runs it and queues the Output and Error events.
As you can see, Executor randomly outputs empty strings in place of messages/errors. After a bunch of runs, it eventually outputs something but the behavior is rather random : sometimes the messages are doubled, sometimes you get only the errors, sometimes only the messages.
On first runs, Executor gives empty strings
Then it works but the strings are fired twice
Only the last print() statement of the python script seems to make it to the output
Tried the same setup with a Sampler instead of HoldLatest and then again, the results are somehow better since all the strings are printed but the results are not consistent :
Ran your test patch here, indeed I get more reliable results here, no more empty output (why does assigning the events to Create fixes that by the way? I mean I get why it makes sense to assign those to Create but why does it produce a different behavior if they’re on Update? Shouldn’t that be “just” less optimized?)
But leaving your patch run for a while shows inconsistent output as well :
I’m a bit puzzled because I don’t see what could go wrong and produce that inconsistent behavior - shouldn’t the process behave the same way all the time?
Anyway, at least now we get something all the time, thanks again!
You might need to recreate whole thing, I was playing around with power shell and I noticed that stuff like process aren’t statically bound to their memory address or more likely shell address might change over time, so when you call for process you have to get instance you are starting it for. it’s might be something similar with executor, basically it in moment it was created the shell instance was one, but after some time shell instance updated but executor don’t have correct address anymore…
I would make some utility and wrap whole executor thing in it to make sure you create new executor for each time you trigger…
I think (but don’t know for sure) when put on Update it “re-subscribes” to the events every frame, so subscription to and firing of the events might “overlap” in a way that the result is not received.
What was the time between the executions? I guess if the period is really short the (python) processes could kind of queue up (maybe one overtaking the other) and their results arriving out of order. Just speculation though.
I’m porting a old beta patch to control stepper motors via TIC USB Stepper Motor Controllers. The commands are send via ticcmd, which i call via the Executor.
For example if the position command is called very often because it is change via the UI, sometimes the process hang and did not exit and flooded the Task-Manager. So it was handy that the process was killed after some time.
heh, so you want to keep it because it helped to workaround another issue you had. hm…
two suggestions:
the preferred way: instead of relying on a commandline tool, why not communicate via serial directly? VL has very premium support for serial communication and this would mean your patch will later also run from other platforms…
alternative: if you need to kill a process started via Executor, use the Kill node
This is the standard way they provide the communication via USB.They do not open a serial port via USB. All there examples doing the usb communication via ticcmd (python example). For serial via usb a extra adapter or device in between is needed and is quite extra effort to implement the serial protocol.
Yeah, was thinking about this way, but what is the problem with the “Wait for Exit” method? So i would reimplementing a function, which is there and was working for me. And the method is just used wenn the value of pin is set. So could it be a hidden pin?
the issue is with the observable outputs not making sense in the blocking case. so if we bring it back it would have to be an extra node that has a different pin signature…
but in your case, as it sounds like a very special “workaround” usecase, i’d suggest you to simply make a copy of the node in your library that works as you need it.
