VIM Demo-HAL

[bbean]

This is a continuation of conversation from here https://lavag.org/topic/19163-vi-macros/?p=115771

 

So I decided to update ShaunR's VIM Event Demo with Xnodes.  Its still rough around the edges, but I think it cleans up the diagram pretty well and adds some benefits to displaying relevant Event names in the Event Structures.  For now I got totally rid of the "name in" input on the event / event register Xnode so you have to name all the constants or controls that go into the Xnode or it won't work.  I could put the name in back in and make it so it would override, but I don't have time right now as I'm preparing for more important things...vacation.

 

Take a look and tell me what you think.  Hopefully I didnt leave out any VIs.  Many thanks to hooovahh as I used his Variant Write repository Xnode as a starting point and have learned a bunch of stuff from his Xnodes.

Xnode Event 2014.zip

[ShaunR]

Nice. Now if only VIMs could do that

 

There was a dependency on an OpenG function. I've replaced it with a native LabVIEW one.

 

SREventXnode.zip

 

Are you thinking about putting the xnode in the CR?

 

 

[bbean]

Are you thinking about putting the xnode in the CR?

 

Sure, just don't have time now.  It needs a few more ability VIs to make it robust and a lot more testing but I don't see why not.

[ShaunR]

Oh yes. Nearly forgot

 

Here is the TCP Telemetry VI that fits in that space on the main diagram that I spoke about in the other thread.

 

TELEMETRY.vi

 

Just drag the VI from explorer and plonk it in the gap in the services-job done. (I suggest you place the VI itself in with the rest of the  subsystems, but it's not a requirement for it to work).

 

Whats that? It doesn't work? It doesn't do anything?

 

Aha!    That's because you haven't connected to it.

Oh, alright then. Here's a simple client to make a connection. Run it and see the candy.

 

TCPIP Telemetry Client.vi

Edited September 7, 2015 by ShaunR

[bbean]

Ok.  I updated the code as follows

 

• renamed the project to VIX Event to avoid confusion since this version doesn't use VI Macros but rather the Xnode.
• Added the TCPIP Telemetry Service and Client

 

• Updated the SREventXnode Help to show help and also the terminal name in the help indicates what the event created is named 
• Modfied the SREventXnode Image so it updates with datatype 
• Fixed some bugs in the SREventXnode code

 

I tried to downsave to 2012 but had some problems converting and errors when I ran the code.  The Xnodes needed to be manually updated and for some reason the in place element structures threw an error saying their reference was invalid in user event cases associated with the Xnode.  This might have to do with UpdateState2 ability in the Xnode which I'll have to look into.

 

Also, I think I want to add back in the variable "name" terminal to the top left of the SREventXnode as the way to name the lookup SEQ.  Automatically generating the SEQ name from the data passed in limits the ability to have multiple "services" of the same type on a diagram.  For instances if you had multiple motion controller axis you would want to have three of the same VI services on the diagram and pass in a name to the service and its VIX events.

 

The other weird thing that happens when you update the name of an input to Xnode is that when its finished generating the code, a mouse click is generated on the diagram and a selection box appears.  Don't know why this is happening.

 

 

VIX Event Test 2014.zip

[ShaunR]

Ok. I updated the code as follows

• renamed the project to VIX Event to avoid confusion since this version doesn't use VI Macros but rather the Xnode.
• Added the TCPIP Telemetry Service and Client

• Updated the SREventXnode Help to show help and also the terminal name in the help indicates what the event created is named Help.png
• Modfied the SREventXnode Image so it updates with datatype
• Fixed some bugs in the SREventXnode code

Sounds good.

I tried to downsave to 2012 but had some problems converting and errors when I ran the code. The Xnodes needed to be manually updated and for some reason the in place element structures threw an error saying their reference was invalid in user event cases associated with the Xnode. This might have to do with UpdateState2 ability in the Xnode which I'll have to look into.

I'm not really suprised you are having these difficulties. When you consider others talking about identifying which features are available in which LabVIEW versions, you know backwards compatibility is broken..So far, no-one has revealed what the common sets are, preferring to play with the latest and greatest.

 

Also, I think I want to add back in the variable "name" terminal to the top left of the SREventXnode as the way to name the lookup SEQ. Automatically generating the SEQ name from the data passed in limits the ability to have multiple "services" of the same type on a diagram. For instances if you had multiple motion controller axis you would want to have three of the same VI services on the diagram and pass in a name to the service and its VIX events.

With your multiple axis motion controller; I disagree. In the service model you would just have a Motion Controller Service and send it X, Y and Z commands or more likely "TABLE>MOVE>PRESET1" or similar.

There should be no reason why you cannot have multiple versions of the same type unless I'm missing something. Only the name string is important and that is derived from the constant label (this is how queues work after all).. The constant's name should dictate the event name, not the data type Even if you do name them the same it is basically a no-op for whichever call gets there second. The events are global so two events with different data-types that have the same name is not desirable or needed and would have so many caveats as to make them unusable, IMO. So I'm not really sure what issue you are trying to solve by adding the terminal back in.

 

The other weird thing that happens when you update the name of an input to Xnode is that when its finished generating the code, a mouse click is generated on the diagram and a selection box appears. Don't know why this is happening.

That just seems to be the motto for Xnodes

A good  improvement on the last one, though. Before, It had the same problems as the VIM and then some. It worked out of the box this time for me so thats great.

[hooovahh]

I also tried back saving it in 2013 SP1 and it also had some runtime error with the in place element structure, which is odd because the only place you are using it is with these DVRs, and one place in the XNode code for being an unbundle/bundle but the error didn't come from there.  I know this has a ways to go before it is code repository ready, but you're going to want to revisit the VI descriptions, lots of stuff in there with my name on it.  Glad you are finding some of my code useful, but it incorrectly identifies what the code is a part of and where it comes from.

[bbean]

 Glad you are finding some of my code useful, but it incorrectly identifies what the code is a part of and where it comes from.

 

Should be fixed in this one.  Sorry about that.

VIX Event 2014.zip

[bbean]

With your multiple axis motion controller; I disagree. In the service model you would just have a Motion Controller Service and send it X, Y and Z commands or more likely "TABLE>MOVE>PRESET1" or similar.

There should be no reason why you cannot have multiple versions of the same type unless I'm missing something.

Think of the scenario where you were a manufacturer who made single axis motion controllers and sold them to LabVIEW developers.  You want to create a single axis "service" so the user can just plop down the VI as many times as he has axis (SP?) and you have no idea how many axis are in his system. could be 1 could be 100

 

I mocked up a crappy example in the project file

 

After going through the exercise, I think you may be right even though it was unintentional   .  You just have to add an extra item to the event cluster contents that describes which axis sent the message.  But the reason I went down the path of trying to have a variable name for the SREvent was so that there could be separate unique events / event handlers in the caller VI to handle each axis separately.  But looking at the approach I took in the code attached, I think its cleaner and less work.

VIX Event w Motion 2014.zip

[ShaunR]

I was meaning using the control label like the following so it uses the same semantics as the event primitives.. The only reason I had a text control with the name in the text was because the VIM wouldn't transfer the label name inside it's macro so I couldn't read it. Otherwise I would have done so. You can do this with Xnodes though I think.

 

 

Hint:

Use messages "UI>MOTION>SET POSITION>x,%.3f", "UI>MOTION>SET POSITION>y,%.3f", "UI>MOTION>SET POSITION>z,%.3f" and have one "MOTION" service instead of having 3 actors.

Edited September 25, 2015 by ShaunR