Error during deploy SDF using veristand 2010 APIs

[ClaudioH]

Hi,

I developed some VIs to connect and download "in4" and they worked fine with VS 2009.

Now I am migrating to VS 2010 and I got error -307658 when I try to connect for the second time.

If I Undeploy using Project Explorer, I always got no errors.

I tried to undeploy using Disconnect from System but I still receive the same error.

With VS 2009 it was possible to deploy the SDF many times without error but it looks that the same is not allowed with VS 2010, is this right?

Am I forgetting something?

I am attaching the VIs and SDF.

Cheers,

Cláudio H.

[StephenB]

NI VeriStand 2010 has two new VIs for deploy and undeploy that are not drop in replacements for the old 2009 "run" and "stop" workspace VIs. I recommend replacing your run and stop workspace VIs with the new 2010 "connect" and "disconnect" VIs in 2010. They are on the palette in LabVIEW, or if you're using a different environment.. They are in the assembly as connect and disconnect.

On connect, one of the inputs is "deploy system definition? (T)" which means the host will deploy the system defintion and connect by default. if you set this false, then it will just attempt to connect and it will return an error if the target isn't already running the same system definition.

On disconnect, there is an input for "undeploy system definition (F)" which means by default when you disconnect, the system continues to run. Set this true if you want it to stop.

You can also add error handling into your code. An example would be calling connect with deploy set false, but if that fails, try calling it with deploy set true.

[StephenB]

I just took a look at your VIs, it seems you have already made these changes and are using connect and disconnect. So while I'm glad what I just wrote is now documented... it's not helpful to you, sorry 🙂

Can you try using the Get System State call to check what system definition NI VeriStand claims is currently running? Can you put together a small single VI that demonstrates this problem? It could be a bug.

[ClaudioH]

Hi Stephen,

I created the method to retrieve the system state and changed my tests.

If I ran

1) Open > Run > Stop > State > Close with deploy set, there is no error.

2) Open > Run > Stop > State > Close with deploy set, there is error.

3) Open > Run > Stop > State > Close with deploy not set, there is error.

4) Open > Stop > State > Close with undeploy set, there is no error

It looks that it not possible to deploy and undeploy in sequence. If there is a delay (big) there undeploy works fine.

But looks that the Deploy is always done even it is set to not occur.

Check the new Class.

Cheers,

Cláudio H.

[StephenB]

I just tried this out:

I put a probe down inside the stop VI so can see if it ever called the disconnect from system call... and it didn't. The path for workspace file came in as blank, so the disconnect from system call never happened. Therefore the undeploy never happened.

So I looked around, and inside your run system definition file VI, you have a VI called read target info. This VI does this:

I probed this VI while it ran and noticed workspace file is blank. Considering the rest of your code relies on workspace file... this is the problem.

1. Your open call sets the "workspace file" as the system definition file (.nivssdf).
2. Your run VI calls your read target info VI which sets the "workspace file" as the workspace file...which doesn't really exist in 2010 anymore and therefore is returned blank.
3. Your stop VI checks if the "workspace file" path is blank and doesn't call the undeploy if that is the case.

Note that the read target info VI is using NI VeriStand - Get Engine State.vi which is noted as deprecated on its front panel. It is suggested to use the get system state call instead... the only difference between them is that workspace file isn't output anymore because that doesn't exist with 2010 anymore.

To fix this. I would update your class so it doesn't use workspace file anymore, just the system defintion file. Since this is a small project, this wouldn't take more than a few moments.

[ClaudioH]

Hi Stephen,

I am changing my VIs and I have a question?

It is correct to assume that when system state is "active" we can not request a new deploy before undeploy?

With similar thinking, if the system is "idle" we can not request an undeploy?

Cheers,

Cláudio H.

[StephenB · Accepted solution]

If the state is active, that means the connection between the gateway (host) and the target is already active. These calls will result:

1. Connect with deploy set false - This will error with -307658 saying that the system is currently running (it is already connected) and you can't reconnect.
2. Connect with deploy set true - This will error with -307658 saying that the system is currently running and you can't deploy.
3. Disconnect with undeploy set false - This will disconnect the gateway (host) from the target but leave the system defintion running.
4. Disconnect with undeploy set true - This will undeploy the current system defintion and disconnect the gateway from the target.

So for a robust implementation you should probably error handle