Jump to content

Recommended Posts

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

Share this post


Link to post
Share on other sites

Nice. Now if only VIMs could do that :yes:

 

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?

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Oh yes. Nearly forgot :P

 

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

post-15232-0-12302800-1441633822.png

 

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? :oops:

 

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. :thumbup1:

 

TCPIP Telemetry Client.vi

Edited by ShaunR
  • Like 1

Share this post


Link to post
Share on other sites

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 post-549-0-34812000-1443147173.png
  • 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

Share this post


Link to post
Share on other sites

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 attachicon.gifHelp.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 :D

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 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

Share this post


Link to post
Share on other sites

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

post-549-0-28519200-1443209198.png

 

After going through the exercise, I think you may be right even though it was unintentional  :blink: .  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

Share this post


Link to post
Share on other sites

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.

 

post-15232-0-40387300-1443212961.png

 

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 by ShaunR

Share this post


Link to post
Share on other sites

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.