VeriStand Steps for TestStand Feedback

[Thør]

>AR_15_Builder

Looking into the underlying API, it appears that the "GetSequenceState" function is looking for a string whose format is "SequenceName:InstanceNumber" where SequenceName is the RT sequence's name without filepath or file extension, and InstanceNumber indicates the n^th time this sequence has been called in the session.

In your case, try passing "Simulated Gas Mixing:1" into the GetSequenceState step, and see if that gets it going.

[Z4CRUZN]

Hi,

   I had a question about the Teststand - Veristand Data logging function. Currently, when datalogging is turned on, it will run at the same rate as the Veristand engine. Is there a way to change the rate of the datalog function, and keep the Veristand engine rate the same? Thanks....

Dan

[ElectricWraith]

It won't make a difference, at least not in my estimation. The data you'd acquire will be the same, since it gets logged at the rate at which the Primary Control Loop is running. So, you'd in effect be reading the same data at a faster rate which will lead to repeat samples, etc.

If you want to acquire data more quickly, you have a couple of options: 1. Increase the PCL rate (not horrible, but not ideal), which will cause a corresponding increase in your CPU utilization %, or 2: Use the VS Embedded Data Logger.

If your VS project isn't too complex, or if you don't have a model running, look at option 1. I took that route recently on a simple project and it worked fine, it just hammers the CPUs on my RT target.

Sorry it's not an answer to your exact question, but hopefully it's of some benefit.

[Z4CRUZN]

Actually, the idea was to read data more slowly. We are capturing data at a 2ms rate, and burning through hard drive space very quickly. Thanks....

[AR_15_Builder]

Hi Andy,

Sorry for the long time to respond, I sent you a PM.

Regards, Chris

[User002]

Z4CRUZN -

This step calls a LabVIEW VI that simply calls the host side VS Logging API.  We simply didn't expose that option.  I believe you can open up the LLB and edit that VI directly.  In that case, you can add the appropriate calls and add them to the connector pane.  Once it's on the connector pane, it will show up in TS when you go to the substep.  From there you can map it to TS variables. 

It's on our list of things to add, and so is multiple logs at the same time.  That one is more complex, and is taking a little while.

AR_15_Builder -

Got your PM. 

[Holt]

We are experiencing an issue that causes TestStand to hang on a "Set Channel Value" step.  If you just use the Engine Demo shipping example and add the embedded data logger so you have the "Log Trigger" and "Log Command" channels.  Then add a "Set Channel Value" step to change the "Log Command".  This should cause TestStand to hang once it gets to this step.  We've tried using an alias and setting the channel directly.  I've attached a picture of the state it hangs in.  Let me know your thoughts.

[User002]

Hey Holt,

Working on another project lately, I found that sadly that should be the case.  What is happening is the Set Channel step sets the value and then polls until it sees that the value propogated across the network and made it to the target.  That's there because the API is asynchronous and it makes little sense in the context of TS and syncronous execution.

The problem is that the Log Trigger channel resets itself to false as soon as it reads a true.  I suppose there's a slim chance that the Set Channel step might read that true, but otherwise it's doomed to hang.  There is a fix we have, but it hasn't made it into the steps yet. 

We would need to add the fix and rebuild the installer. What timeline do you need a fix by?   And what versions are you using?

Stay warm out there!

Andrew

[Holt]

HandyAndy,

Ah.  This makes sense.  If you can get it to us by the end of next week that should be fine.  We are using TS 2014 32-bit and VS 2014.  Thanks!

Holt.

[D4N!3L3]

I've encountered the same issue with the ECUMC custom device where the "connect" signal is reset to 0 from the custom device itself.

To circumvent this issue i've made a modified version of "Set Value" that includes a (fixed) timeout. If a timeout happen an error is raised. I ignore the error when I use the step to set signals that automatically reset.