Re : Re : Calling Main and Extra Pages of Custom Device(s) from LabVIEW

[DaHelmut]

Hi Steve,

Let's be clear, I don't want to remove a System Definition from VeriStand..I never wrote that...

I want to have access to the same functionnalities of the System Explorer window concerning the Custom Devices section but in my application and that for ANY custom devices.

You have to understand that this is not only concerning my own custom devices.

For example, I am planning to use the XCP and CCP custom device that NI provides WITHOUT the source code. The workaround given by NI (use the offline API) doesn't work in this case.

In the test benches of my company the operator may need to change the configuration file of the ECU (A2L file) so I want the operator to have access to this kind of parameter in my GUI. If I have to re-create all the functionnalities of this custom device in my app...I'd better hung myself.

Also, we have several instruments that may need some configuration for example AVL Indicom : we have to add specific channels before deployment, etc...In this case I could create another VI that will control my custom device before the deployment of the system definition file...But if I already did it with the custom device template (i.e : Main Page and Extra Page(s) of my custom device) why would I do it again with another VI ? This is a nonsense, I get the double of work with this kind of method and it only works with my own custom device. Moreover, I think that NI do not recommend modifying the XML file of a System Definition without the API calls.

To be clear : I want to configure ANY custom device in my own GUI that will be controlling the test bench. There will be 2 parts in my GUI : configuration page before the deployment and the execution page that will allow the user to view and control the channels, variables of the system.

I think there are functionnalities missing in the System Definition API.

The errors that I got made it clear : I am missing a library that is internally loaded from System Explorer.exe 

I know what I am asking is not possible, but I thought NI would have given me a better workaround than replacing the API with the Offline API or changing the system definition file properties to protected (I don't even think it's possible but we don't have access to the XSD file too).

Finally it seems that if I want to let the operator to have access to the System Explorer window I have to buy a full development license or a PC development license.

Is VeriStand really made for industrial purposes where the configuration of a test bench may change several times a year without the need of a developer license ?

In my company we are testing combustion engines and sometimes (depending on the manufacturer of the engine) we have to change the ECUs parameters, the type of measurements, the instruments that are available, etc...

I know I may seem angry but I am frustrated that I cannot really do this basic thing in my own GUI when NI sells it as a revolutionary solution.

Regards,

[StephenB]

Hi DaHelmut,

First of all, I apologize for the lack of applicable replies. What you're attempting isn't something we usually encounter so our team didn't quite understand.

I'll restate what you want to make sure its clear: You want to make your own version of system explorer fir your team to edit system definitions with. You also want it to support configuring custom devices. Therefore, you need custom devices to work inside your system explorer just like they do inside the shipping system explorer.

This is technically possible, and I will help you accomplish this with some advice, however I have never seen this done before so it might take us a while to figure out all the issues. Typically people developing a custom GUI for a test bench just use the system definition API directly instead of using custom device's as-is... which is more difficult, and I agree your approach is better if it works. However, most test benches have a known set of custom devices (maybe just XCP/CCP and scan engine) so they only need to use the system definition API for maybe a few custom devices... not any device.

First things I should mention:

• Editing a system definition, either through your custom gui and therefore through the system definition API, or through the system explorer... always requires a PC or Full development license. An operator licenses will never be able to edit system definitions no matter what.
• There is a set of VIs provided by the ECUMC toolkit to add/remove/edit system definitions with the XCP/CCP custom device. You would have to put your own GUI on top, but the VIs are installed here: <\LabVIEW>\vi.lib\ECUMC\NIVS
• I have an unreleased set of VIs that do the same thing for the scan engine and ethercat custom device I can provide

If you still want to create your own system explorer thats capable of loading and configuring any custom device, here are some suggestions:

Custom devices are built into LLBs that include all of their dependencies, so they can be loaded by the LabVIEW run time engine. If you create a VI that loads custom device's, you should be careful to avoid cross linking corrupting your development system or your custom device's. For example your system explorer might use "Get File Extension.vi" from vi.lib, but the custom device you're loading might also use this VI and therefore its linked to a copy inside its LLB. You will know when cross linking happens when the LabVIEW load warning dialog appears saying "vi X loaded vi Y from Z instead of A". If that happens, do not save. To avoid this entirely, it might be easiest to test your system explorer only as a compiled exe.

As you saw, some custom device API VIs used by custom device developers make dynamic VI calls to an in-memory library named "Custom Device Storage.lvlib". Since this library is part of the shipping system explorer.exe source, these dynamic calls will error when not run inside the shipping system explorer.exe. There are two types that must be handled separately.

• Some custom device APIs like "NI VeriStand - Signal When Ready for Shutdown.vi" just make this dynamic call, and will simply return an error. These are mostly system explorer GUI specific custom device APIs. To avoid this error, you must create and bring this VI into memory yourself. So create that library and the stub VIs you need, then place static VI references to those stub VIs on your custom system explorer's block diagram. That will bring them into memory so when the custom device VIs try to dynamically call them, it will not error.
• Most custom device APIs like "NI VeriStand - Get Item Description.vi" make the dynamic call and instead of simply erroring, they will instead catch the error and switch to using a .NET implementation of the API call. I advise looking at the block diagram of this VI and then the corresponding offline API VIs to better understand this redirect system. Unfortunately, this redirection gets the offline API VI path relative to vi.lib which doesn't exist for exe's. So when you build your custom system explorer into an exe, you will need to place the "NI VeriStand\Custom Device Offline API" folder adjacent to the exe with these VIs for them to be found because the "vi library" primitive returns the exe's directory when inside an exe

Let me know if that helps or if you have questions.

[DaHelmut]

Hi Stephen,

First of all, I must apologize from my side too, maybe I was not clear enough thus your team didn't really understand my needs.

Thanks for your answers and I agree that most of test benches in general are made of static custom devices that may not change during its lifetime.

In my company, things are more complicated than that because we have several instruments / controllers that are interchangeable from one test bench to one another depending on which combustion engine we are testing and what our customers want to measure / control.

That's why we were evaluating VeriStand to find out what were the benefits and drawbacks of using it with LabVIEW via its API.

Also, it is now clear that the API calls depend also on the license type we have. I keep it in mind.

Finally, I will try both solutions you gave and I will let you know the results. 

Thanks again for your answers. Have a nice day.

Regards,

[Thierry_38]

Hello,

I meet the same problem as DaHelmut when using the "Custom Device API" in an application built in Labview:

My need is the following:
I have to manage many configurations of a test bench and so I have many VeriStand projects.
When I have to update the test bench or I do a correction, I have to modify all my projects.

In order to ease this process I have done an application using the "System Definition API" to automate the SDF building. So my application adds the FPGA bitfile, the model dll, the Custom Devices, does the mapping and imports the aliases file.

The drawback is when I add a Custom Device using the "System Definition API", I have to re-add all channels (The reason is that adding the Custom Device programmatically does not add the channels neither their properties). So my solution was to call the "Initialization VI" of the Custom Devices.

the problem I encounter
Doing so lead to the error reported by DaHelmut.
I investigated this error and I found the problem: the "Custom Device API" VIs uses the "VI library" to built the path of "Custom Device Offline API" VIs !

If I use the solution to rebuild all Custom Devices using the "Custom Device Offline API" (this workaround is very painful), then I encounter a new bug when I try to add the modified Custom Device using the "System Explorer": the view is not updated even if the channels are well added in SDF !
-> The solution that consists to use the "Custom Device Offline API" instead of the "Custom Device API" is not good method.

My requirements:
I expect that the Custom Device API shall be modified to correct that in the next version of VeriStand.

It will be nice to add in the "System Definition API" a constructor for Custom Devices that takes as input the Custom Device XML file. this constructor then add all the channels.

Regards