VeriStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Controlling VeriStand from 64-bit LabVIEW

Solved!
Go to solution

So, I know VeriStand does not have a supported 64-bit API (at least not in LabVIEW, which is what I'm using).  However, I am using 64-bit TestStand because there are a few libraries I need to call that are 64-bit only supported.  Everything I'm doing in LabVIEW works in 64-bit except for VeriStand automation, so I've ended up using the VeriStand custom steps for TestStand.  However, these are super buggy.  (I've filed three bugs in the last three weeks and just found another today).  I know that there are these new steps that are NI-supported, but one of the other  issues with controlling VeriStand with TestStand steps in general is that any kind of detailed sequencing of VeriStand channels is incredibly tedious.  There are, for example, scenarios where I want to sequence 20+ CAN and digital commands with some conditional logic.  It makes sense to put all of these in one reusable piece of code, so I've placed them in a subsequence, but the debug experience is still pretty lame, and some of the conditional error handling I want to do gets packed away into hard-to see step expressions and statuses.  It's a real mess.  I could use real-time sequences, but they lack flexibility and error handling that I really want to give good user feedback.  (For example, if I don't get a return message in X amount of time, I want to program some other commands and digital channels, maybe do some retries, error in specific ways, etc.)  If I could just put all of these channel configs into a single VI with the error handling and looping/timeouts/etc. much more easily visible, it'd make my life a lot easier.

 

So, my question is whether anyone else has come to find a way to automate VeriStand from 64-bit LabVIEW.  I took a look at the custom step type source on GitHub, and it looks like LabVIEW code, which implies that it must be 32-bit LabVIEW since there's no 64-bit VeriStand API in LabVIEW.  Does anyone know how this works?  I can't seem to figure it out.  Is there a special 64-bit build of the .NET assembly?  Do the steps do some interprocess communication?  I've tried just mass compiling the VS APIs in vi.lib in 64-bit LV, and I get broken VIs and all manner of problems (not a surprise, considering I think that the assembly and the VS application are both 32-bit).  Could VeriStand R&D let us know if a 64-bit API is on the horizon or whether there's a 64-bit .NET assembly?  Any advice would be appreciated.  In the meantime, I'm going to power through with the custom step types, bugs and all...

0 Kudos
Message 1 of 6
(3,460 Views)
Solution
Accepted by topic author croohcifer

Hello croohcifer,

 

Thanks for checking out the new VeriStand ASAM XIL Steps for NI TestStand. As you are probably aware, these steps were created by VeriStand R&D and are fully supported by NI. If you find any bugs in these steps, we would be happy to help you investigate it.

 

Can you automate VeriStand from LabVIEW 64-bit?

I have a couple of ideas on this. First, the ASAM XIL API and the VeriStand ASAM XIL Steps for NI TestStand are 64-bit compatible starting in VeriStand 2018. You can use those steps or write your own steps based on the ASAM XIL API that is included with VeriStand. If you choose not to use the new steps, I would be curious to know what you would like to see improved or how your workflow differs from what the steps provide.

 

Also, UI Manager is 64-bit so the .NET API assemblies that it calls, such as the Client API, are 64-bit compatible. I would expect these to work in TestStand as well.

 

Thanks,

 

Andy 

Product Support Engineer

Message 2 of 6
(3,447 Views)

Thanks Andy,

 

Interesting point about the Client API.  I'll try mass compiling a subset of the VS API and see if I can get those working in 64-bit.  I'm unfamiliar with the ASAM XIL API.  Is there a LabVIEW wrapper for this, and would it provide different functionality than the Client API?  I'm really looking to control VeriStand from LabVIEW, so if I'd have to wrap the ASAM functions myself, I'd see it as a burden and probably not worth the time if the Client API will just work.  I only see NI-supported ASAM TestStand steps.  I don't see a LabVIEW API for download, but please point me to it if one exists!

 

Does NI R&D have plans to add Client API (or even more VS APIs) support to LabVIEW 64-bit natively?  I'd be nice to see this as a first class citizen in LabVIEW and on the palettes if you're already using the underlying .NET assemblies in the 64-bit UI Manager.

 

David

0 Kudos
Message 3 of 6
(3,435 Views)

Hey David,

 

There is not a wrapper for the Client API in LabVIEW 64-bit nor is there a wrapper for the ASAM XIL API. I am not aware of any plans to add the VeriStand Execution Palette to LabVIEW 64-bit. Personally, I had not even thought about it until your comments today. Thank you for the feedback. I will pass it on to the team. However, it does not necessarily help you with your current project. 

 

Thanks,

Andy

0 Kudos
Message 4 of 6
(3,428 Views)

Hi Andy,

 

I've mass compiled just the Execution API and tried a few functions.  It appears to be working in 64-bit LV, which is pretty neat!  I'll update the forum here if I find limitations.

 

Thanks,

David

0 Kudos
Message 5 of 6
(3,421 Views)

Hi Andy,

 

Two things.  Firstly, the standard VS libraries (Client, Execution, Sys Def APIs) work in 64-bit as expected.  Hooray!  Secondly, the XCP Add-On System Definition API isn't cooperating quite as smoothly in 64-bit.  (Also, feel free to route me to the CAN team if you don't support this CD.)

 

To be more specific, I am referring to the contents of this folder:  C:\Program Files (x86)\National Instruments\LabVIEW 2018\vi.lib\ECUMC\NIVS

 

I have mass compiled them in 64-bit LabVIEW against my 64-bit Custom Device VS APIs and have no bad/broken VIs.

 

Background: I have four A2L files for four variations of a part, and the only thing changing from one A2L file to another are the DTO and CRO IDs for the XCP slave.  Instead of maintaining four separate system definitions, nearly 100% of which would be duplicate content (except for the A2L file paths and the two IDs), I decided to go down the route of programmatically changing the A2L in the sys def before deploying so I could handle four parts from one sys def.  This will save us a lot of headaches in the event that we have to change any shared component like a model, DAQ channel, sensor scale, etc. because we'll only have to change it in one place instead of four.

 

Current Issue:  Basically, I'll always have a "default" A2L in the sys def, and in my test program, I want to find the custom device that has the "default" A2L file in the sys def and replace the communication properties (DTO and CRO IDs) with those from the "new" A2L file.  Attached is a VI (a simplification of Lynn's example here) that does exactly this with no issues in 32-bit LabVIEW.  Here's the heart of the code:

 

Capture1.PNG

 

In 64-bit LabVIEW, "Get Custom Device Properties.vi" (the VI on the left) works perfectly and returns the existing values in the sys def, but "Set Master Properties.vi" (on the right) returns this:

 

Capture.PNG

 

My host computer is a standard installation of Windows 10, and I've tried changing my target OS in the sys def to both Windows and Phar Lap but have received the same error.  Because this same VI doesn't error in 32-bit LV on the same computer with the same sys def, I don't actually think it has anything to do with my OSes.  My guess is that there's an assembly or other piece of LabVIEW code that is compiled in 32-bit only, but I can't know for sure because the "Set Master Properties" VI is password-protected.  I'd be happy to look into this myself if I had the password if NI is willing to share.  If not, I'm asking if NI could look into this and let me know if I'm SOL because there's truly a 32-bit component that has no 64-bit equivalent or if there's some other workaround than maintaining four system definitions.

 

One Workaround I've already looked into:  I at first thought that if the above was going to be such a hassle, why not just change the XML directly.  Unfortunately, while the A2L file path is in plain text, the Communication Properties (which contain the DTO and CRO IDs) is some kind of encoded string, whose format I have no way of knowing:

 

Capture2.PNG

 

When I diff the strings after changing from one A2L to another (again, only the two IDs are different), a huge quantity of the string in the sys def is different, so it's probably not just some simple conversion I could reverse engineer.  In principle, calculating an encoded hash shouldn't be limited to 32-bit operations only, so I know what I want to achieve is definitely possible in 64-bit.  I think I've exhausted what I can do with the information I have, though, so I'd appreciate any further insight you may be able to provide!

0 Kudos
Message 6 of 6
(3,082 Views)