How to specify finite simulation stop time in VI generated using SIT connection manager

[Gayatri Damle]

Hello,

I have a SIMULINK model which I want to run on a desktop ETS. I'm following this procedure:
1. Convert the SIMULINK model in a .DLL using RTW build in Matlab. The target of this build is nidll.tlc.
2. Create a host VI with required indicators and map the parameters using SIT connection manager.
3. Configure the DAQ (and then SIT connection manager generated the driver and IO files for me.)
4. Using LV project, run the driver on the desktop ETS and host VI on the host machine.

The code is working fine, without any error.
My question is this: Since in the driver VI, the simulation time is set to -1, which implies "continuous", the simulation goes on until I hit the stop button on the host VI.
I tried changing this default value to some other value. The simulation then does run for the defined amount of time but then I'm getting error 2206.

What is an appropriate way to stop the simulation on the RT target?

Thanks
Gayatri

PS: I'm using LV 8.5, LVRT 8.5, SIT 4.0, Matlab @2007a.

[Jarrod_S.]

It sounds like you are doing everything correctly. This is a known issue with SIT 4.0 and has been reported to R&D for further investigation (CAR# 104172).

It should be noted that this is purely a cosmetic (albeit inconvenient) problem. The simulation is shutting down properly. The problem is that the Server Loop in the Driver VI that communicates over TCP with the Client VI tries to poll the current status of the simulation after the simulation has already stopped and shut down the FIFO used to keep track of the status. This generates the error you are seeing.

[Gayatri Damle]

Hello Jarrod,

Thanks for your comment.
So according to you, even though there is this error coming up, the SIT has generated correct values and I can ignore the error for now and analyze the values that I get.
Just wanted to make sure I'm getting you right 🙂

Thanks again.

Gayatri

[Jarrod_S.]

That is correct. The simulation has shut down properly, and your data should be valid for analysis. This is simply an error in how the Client VI and Driver VI interact when the Driver VI stops the simulation by itself. The Client VI detects that the simulation has stopped and responds by telling the Driver VI to stop, which it can't do because it already has.

Long story short, you can ignore this error, but I understand it's inconvenient that you have to.

[Gayatri Damle]

Hello Jarrod

I have one more question related with the same application. Is it possible to have different sampling times in the SIMULINK model and the driver VI?

I'm getting DAQmx error 209802. I talked with the AE and after our discussions we figured that it looks like the processor on the desktop ETS is not able to solve the system in time and so the samples are missing, and so the error.
Now if I increase the time-step in the model, the simulation runs, but the increased time-step not desirable for my application. ( and upgrading the desktop ETS to a better processor is also not possible right now.)
So I was wondering if there is some way I can tell the driver VI to look at the samples not with the model time-step but with a larger time-step.
e.g even though my model has time step of say 1000usec, I want the driver VI to run at may be 2000usec, i.e consider only selected samples.
Is it possible?

Thanks
Gayatri

[Jarrod_S.]

The VI in the Driver VI called SIT Initialize Model.vi has an input called time step (sec) (-1: use model time step) which does what you want it to. It doesn't actually affect the time step of the solver used in the built model DLL, just the rate at which the main base rate loop actually runs in real time. In fact, base rate loop period would be a better name for this control. If you set it, you won't alter your model, but you will be able to adjust the rate of the base rate loop.

Simply create a control from this input terminal on your driver VI and fill in an appropriate period in seconds. Make sure to set this value as default in the control so that the Driver VI remembers it.

You will have to take into account that your model will still think it's running at the time step it was compiled at. So your model simulation time and the actual wall clock time won't match up.

[Gayatri Damle]

Hi,
So does that mean the data observed won't be "real-time" even though the model is running on the RT target, since we messed up with the base rate loop which was set by the model itself.

Gayatri

[Gayatri Damle]

Hi,
I just realized that since the base rate loop eventually determines the rate at which values are generated from DAQ card, changing the base-rate-loop period will change the frequency of the output generated from the DAQ card.
Is it correct? If so, then even though the application runs without any errors, the actual output generated is of erroneous frequency (which essentially is some multiple of the desired frequency)

Note: the DAQmx error I mentioned is now removed as the increased loop period makes sure the DAQ receives values in time.

Please comment on this.


Thanks,
Gayatri