LabVIEW
What am I doing wrong with asynchronous call and forget?
I guess you can use the Windows game-bar (Win-G) to record the screen but you'll need something else to turn it into a gif. Apparently Clipchamp can export as GIF, but only max 15 secs and very low resolution.
@Yamaeda wrote:
I guess you can use the Windows game-bar (Win-G) to record the screen but you'll need something else to turn it into a gif. Apparently Clipchamp can export as GIF, but only max 15 secs and very low resolution.
My corporate IT disabled the Windows Game Bar for recording. I just installed ScreenToGig (surprisingly on the allowed software list). I haven't played with it yet, so I have no opinion at the moment. For my GLA Summit presentation, I used the screen capture through Power Point. I don't know if I can export that object to a gif though.
wiebe@CARYA wrote:
"So you might want to open VI references at initialization. Easier said then done, as you'd need to know in advance how many references you need."
As long as you know which VI you want to call dynamically you can open the reference during initialization and use that reference to spin up as many copies as you want.
By default this creates a "call pool" of 5 instances which are ready to run "deterministically". You can use an invoke node to change that size to cover what you expect as likely. The root loop does not block creation of VIs beyond the size of the call loop though (at least it did not seem to when I rechecked that just now 🤔) just its speed, so knowing up front what pool size to use is normally not critical.
We use this e.g. to spin up TCP session handlers where we want to be able to call and forget a new handler for every incoming session even if the local user is blocking the root loop:
@Mads wrote:
wiebe@CARYA wrote:
"So you might want to open VI references at initialization. Easier said then done, as you'd need to know in advance how many references you need."
As long as you know which VI you want to call dynamically you can open the reference during initialization and use that reference to spin up as many copies as you want.
By default this creates a "call pool" of 5 instances which are ready to run "deterministically". You can use an invoke node to change that size to cover what you expect as likely. The root loop does not block creation of VIs beyond the size of the call loop though (at least it did not seem to when I rechecked that just now 🤔) just its speed, so knowing up front what pool size to use is normally not critical.
We use this e.g. to spin up TCP session handlers where we want to be able to call and forget a new handler for every incoming session even if the local user is blocking the root loop:
OK, we have another quite technical potential (unconfirmed 😉) workaround for something that should, intuitively, just work. I'll have to play with that at some point. I hope I remember the trick when I need it 👴.
(I think) this is only a solution if you have the connector pane type though?.
It's still (also) silly there isn't any way to call a normal non-idle subVI if you don't know the connector pane (as described in Run As SubVI method - NI Community).
Search LabVIEW like a graph! 