03-20-2019 09:37 AM - edited 03-20-2019 09:43 AM
Hey guys,
Hope you’re all doing good.
Does anyone of you have compared communication performance between LabVIEW and CANoe System/Environment variables using Shared Variables vs ActiveX? I’ve had some issues with past projects using ActiveX specially with memory leaks (I'm 100% sure I was closing all references). I don’t find the ActiveX method to be very reliable for continuous variable access from LabVIEW to CANoe so I would like to know if you have any experience using Shared Variables instead. Do you recommend them for this purpose? Have you seen any latency issues between LabVIEW and CANoe using this method?
All the best, Luis CT
03-20-2019 11:13 AM
I remember looking into shared variables for a past project which required passing data between 2 PCs and I observed a latency issue when doing that. All I did was create a shared variable that was to indicate the value of a boolean switch and when I changed the switch on PC1 it sometimes took seconds to see the update on PC2.
I believe shared variables worked better if you used them on the same PC but this was not my application so I don't exactly remember if there were any latency issues.
Though, I will second your issues with ActiveX. There are unknowns when using ActiveX which can lead to memory issues as we have observed in past projects.
03-20-2019 12:58 PM - edited 03-20-2019 01:12 PM
Hey Dave.
Thanks for your input. My project is running the CANoe configuration in the same PC but will have to handle a considerable amount of environmental and system variables from CANoe. I don't expect determinism but I expect to have a reliable communication method.
Thanks.
03-20-2019 01:31 PM
You could try ASAM XIL APIs, I haven't done much with them myself but the standard is supposed to be specifically for this sort of thing, interoperability between different test software.
Looks like it's implemented as a.NET library
03-20-2019 01:56 PM
Hey Will,
According to the API manual it looks like that method needs a .NET wrapper in C#, VB etc (I guess because it needs exception handling) which you can call then from LV, or TestStand. I was looking for a more direct method but that could be another option if the Shared Variables don't work as expected.
Thanks for your input.
03-20-2019 05:15 PM
Luis,
As you may know, the DGE / FEV TST software uses ActiveX to communicate with CANoe. Other than giving the system time to open CANoe when you start your program (if CAN communication starts up automatically on program start like it does with the TST) I haven't seen any problem with memory leaks and some of the setups I had would run for weeks without problems, sometimes longer.
Bill
03-20-2019 06:26 PM
I can't answer the comparison between Shared Variables and ActiveX, as I have only used ActiveX. I also have not experienced memory leaks with the Environment Variables.
However, I did help out another developer who was having memory growth/leak issues with the CANoe ActiveX interface despite the DETT not detecting any reference leaks. He was using FGVs to hold all of his references, including a single environment variable reference. He then overwrote that environment variable reference whenever he wanted to read/write an environment variable (calling GetVariable, possibly with a different name input, each time). He then only closed that one environment variable reference at the end of the test.
I changed his code to track an array of environment variable references (one element for each unique variable name) and close them all at the end of the test. This eliminated the memory growth/leak. Is it possible you were doing something similar?
03-21-2019 09:27 AM
No, I wasn’t using FGVs to hold references. This is the method I was using:
To make things simple I created a small library that basically had that code divided in Open, Read/Write and Close. I used a cluster to transport the references within a while loop. Nothing complicated.
Now, here’s the tricky part. If I was accessing only 1 Environment or System variable that resides in the same CANoe Namespace there were no issues, all good, no memory leaking. But if I wanted to access a different variable residing in a different Namespace I had to close 3 references (the current variable, the current variable list and the current Namespace) and open them again for the new variable. This process is the one that caused the memory leak and I couldn’t get rid of it.
So, for my new projects I don’t want to spend time with these type of ActiveX “unknowns”. If Network Shared Variables provide the same functionality with no latency issues in the same PC for several Environmental/System variables, I’ll use that method.
The other method would be the ASAM API that @blackburnite suggested but that will require a wrapper in between.
Any thoughts on this will be appreciated.
Thanks!
03-21-2019 11:04 AM - edited 03-21-2019 11:21 AM
Are you looking at the CANoe .NET API or specifically the ASAM XIL API, which is also .NET? I could see needing to wrap the general .NET API because it could have generics that LV can't work with or special exception handling requirements.
But I would think the ASAM XIL should be compatible without a wrapper since NI is one of the ASAM members and it is supposed to be a standardized interface.
EDIT: Oh you know what could be an issue is telling LV where the CANoe specific child of ITestBench is since there isn't an equivalent of the C# using keyword in LV. That would make sense why you would need a wrapper for that too potentially.
11-20-2019 11:57 PM
Network shared variable has the capability of sharing the data in high speed compared to the *.dll, what i feel
I have used both the communication method and found that Network shared variable is better as compared with Activex *.dll methods