Jump to content

Dear NI


Neil Pate

Recommended Posts

3 hours ago, X___ said:

And meanwhile, Colonel Kodosky is mulling the future of LabVIEW in his fortified Texas compound...

 

 

I don't know why they continue to push these "place a VI that transforms into a mess of code". It always seems to me they are solving the symptom, not the cause, by automating the replication of boiler-plate code we have to do when the real goal is not to have to replicate at all.

A long time ago I posted a VIM that, awkwardly, implemented "named events" and the "framework" was to use that and a queue with a bit of string manipulation to send messages back again. It was basically the the same as MessengerM, shown here. It would have been much better if the event structure could use named events (wire a string to the terminal?) and have an [optional] output on the right hand side for a message out/back. That would implement the MessengerM without all this malarky. Certainly in a lot of the event driven API's I now produce, there is a "Source" on the left side of an event structure. That could just be wired across to a "target" on the opposite side to send a message back to an individual stack (aka a queue output). Bonus points if the "target" can be marked as "broadcast" to behave as "Generate user Event". I dare say that it could be refined further with a bit more thought too, since what we have to do is figure out who sent the message and act accordingly-the event structure already knows who sent the event.

Edited by ShaunR
Link to comment
40 minutes ago, ShaunR said:

I don't know why they continue to push these "place a VI that transforms into a mess of code". It always seems to me they are solving the symptom, not the cause, by automating the replication we have to do.

A long time ago I posted a VIM that, awkwardly, implemented "named events" and the "framework" was to use that and a queue with a bit of string manipulation to send messages back again. It was basically the the same as MessengerM, shown here. It would have been much better if the event structure could use named events (wire a string to the terminal) and have an [optional] output on the right hand side for a message out/back. That would implement the MessengerM without all this malarky. Certainly in a lot of the event driven API's I now produce, there is a "Source" on the left side of an event structure. That could just be wired across to a "target" on the opposite side to send a message back to an individual stack (aka a queue output). Bonus points if the "target" can be marked as "broadcast" to behave as "Generate user Event". I dare say that it could be refined further with a bit more thought too.

What are you referring to? "futuristic" features or "super-futuristic" features?

Personally, Colonel Kodosky's vision scares the bejesus out of me. I imagine an application whose diagram contains a single icon of itself, which when you click into it, sucks you into the matrix and shreds you to bits... I mean wires.

Link to comment
On 1/28/2022 at 6:48 PM, X___ said:

Personally, Colonel Kodosky's vision scares the bejesus out of me. I imagine an application whose diagram contains a single icon of itself, which when you click into it, sucks you into the matrix and shreds you to bits... I mean wires.

 

Just watched the video 

2022-02-02_9-03-47.jpg.a657807932ea9ad156e23131c4399ed5.jpg

 

 

Edited by Phillip Brooks
  • Haha 1
Link to comment
45 minutes ago, Phillip Brooks said:

 

Just watched the video 

2022-02-02_9-03-47.jpg.a657807932ea9ad156e23131c4399ed5.jpg

 

 

Yes. It's not a new idea, BTW. This is the route ladder logic went for state machines in PLC's.

Ignoring the boiler plate scripting for a moment. What is really missing is an intuitive way to view a program's structure. I said a long time ago that we need something similar to (the now defunct) Firefox 3D View. This could be a mode of the VI Hierarchy diagram allowing us to inspect the way subVI's are interconnected and allow us to zoom in and isolate areas of interest.

Event and queue [message] tunnels or the "Channels" could easily be shown which are invisible with the tools we use today.

 

Link to comment

I can see why it is defunct...

Personally, I would settle with fixing all the decade long bugs and having support be more useful than it has been my experience. Kind of gnaws at one's desire to engineer ambitiously when one has to hack around bugs or longstanding issues.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.