Custom Workspace Object "Forgets" Its Channel Mapping...

[swbpnole]

I have a custom workspace object that does not seem to “remember” or keep its channel mapping. When I deploy the custom device, it is like the channel mapping is not getting saved. I used the tutorial from here:

http://www.ni.com/tutorial/9989/en/

I used the configuration dialog and the free label diagram, as instructed. However, I used the more recent channel select dialog VI from here:

http://www.ni.com/example/31266/en/

This was done because the stock channel select VI on the tutorial site does not work and only produced a window in a constant “pause” state when running in VeriStand.

Is there any way to make the custom workspace object remember its channel mapping like the stock VeriStand objects do? The stock controls and indicators for VeriStand will keep and remember their channel mapping even when the workspace is closed. I will attach the VIs here.

[swbpnole]

I have created a separate project with the updated changes suggested by the NI Application Engineer. I still see no change in behavior, the workspace object "forgets" its channel mapping upon closing of the entire workspace. Files attached.

[swbpnole]

I also noticed that if the channel mappings remain (i.e. not closing the workspace), changing the values of the controls does not seem to trigger channel changes.

[swbpnole]

***Partial Victory***

I discovered the channel value change issue was related to the fact the I had specified each dial to also make their digital displays visible in LabVIEW:

Just on a whim, I removed the digital displays:

Rebuilt the custom workspace object, installed it to the proper folder for VeriStand, and re-added the custom workspace object to the workspace. Next, proper channels were mapped to each dial and the custom device was redeployed. The change in value for the dials triggered a value change for the mapped channels and the CAN messages were now being transmitted. Woo!

Lesson: For using LabVIEW dial controls in a custom workspace object for VeriStand, make sure their digital displays are not visible as this will cause a channel value change issue with VS when running with a custom device. One would think a build error would occur alerting the user that such an arrangement (dial with digital display visible) is illegal or something. No warnings or errors on my end...

[swbpnole]

For information purpose, I am using LabVIEW 2015 and VeriStand 2015...

[StephenB · Accepted solution]

I took a look at your code. The problem isn't because of the digital display like you said. Instead the problem is because you're not actually saving the mapping. The way you're saving data to veristand's storage is all wrong 😞

• In your LaunchConfigDialog event handler, you're saving the object label
• In the timeout event case (which is being called at 100Hz) you're saving the object label
• In the value change event case, you're saving the control values (which you restore to the controls at startup- which is not right because thats just the last value you set them to with this control not the current system value)

I'm fairly sure you dont want to do any of that. Instead you should simply save the channel paths after they are selected in the LaunchConfigDialog event handler. You shouldn't set custom data anywhere else. Once that is done, you will get those paths out of the custom data variant (left side of your code) next time your control runs, and then you can read their current value to initialize the controls, and you can set the initial value of your shift register so that it has the saved channel paths ready to go for when someone clicks on the controls to change the value.

Also, you should change your timeout value to 66ms. VeriStand data only goes to the host at 15 Hz. No reason to go faster. Also, you should read the channel values and set your controls here to keep them in sync with the system. That way if two of your controls are dropped and mapped to the same channels... when you move one dial the other one moves to reflect the current system value. Same thing goes if a stimulus profile is playing, a channel fault happens, a mapping happens... etc. You want your controls to both allow setting the channel value but also to reflect the current system value.

[swbpnole]

I took a look at your code. The problem isn't because of the digital display like you said. Instead the problem is because you're not actually saving the mapping. The way you're saving data to veristand's storage is all wrong

• In your LaunchConfigDialog event handler, you're saving the object label
• In the timeout event case (which is being called at 100Hz) you're saving the object label
• In the value change event case, you're saving the control values (which you restore to the controls at startup- which is not right because thats just the last value you set them to with this control not the current system value)

I'm fairly sure you dont want to do any of that. Instead you should simply save the channel paths after they are selected in the LaunchConfigDialog event handler. You shouldn't set custom data anywhere else. Once that is done, you will get those paths out of the custom data variant (left side of your code) next time your control runs, and then you can read their current value to initialize the controls, and you can set the initial value of your shift register so that it has the saved channel paths ready to go for when someone clicks on the controls to change the value.

 Also, you should change your timeout value to 66ms. VeriStanddata only goes to the host at 15 Hz. No reason to go faster. Also, you should read the channel values and set your controls here to keep them in sync with the system. That way if two of your controls are dropped and mapped to the same channels... when you move one dial the other one moves to reflect the current system value. Same thing goes if a stimulus profile is playing, a channel fault happens, a mapping happens... etc. You want your controls to both allow setting the channel value but also to reflect the current system value

Not trying to sound "smart", but I followed the tutorial here:

http://www.ni.com/tutorial/9989/en/

It seems the tutorial is doing the same thing I am? It seems like it is the right thing to do based on there.

[swbpnole]

As I indicated earlier, the digital display was interfering with the channel change value triggering from the dial controls for some reason I do not know why. No matter what the core reason for that, on a whim I removed the DDs from the dial controls, rebuilt and reloaded to the workspace in VeriStand, the channel value change triggering and value transmission is working. The issue still remaining is the channel mapping being dropped when the entire workspace is closed then reopened, which by observation is separate from the DD issue. Files for the most recent P Control attached.

[Jiri_K]

Hi swbpnole,

what StephenB said is exactly what you have to do.

~Jiri

[swbpnole]

As I drove home last night I thought about this more. I am now convinced and will try some of the suggestions. However, given the the amount of controls I plan to use and the fact that the multiplexing channel will need different values depending upon which controls changed, I did not see why having differing event cases for different controls changes is worst than having all changes for all controls in one timeout case...