Why does the DAQ assis. inputs not work in pgm but does work when inside the DAQ

[Vamp]

When I try to use the DAQ assistant in a program, it doesn't always use the new parameters that are fed into it. Instead it uses what ever was previously in it. When this happens, if I open the DAQ assistant, manually change the parameters, and run each step it works fine. I really need it to be automated though.

[Dennis_Knutson]

What parameters are you talking about? What sort of DAQ Assistant are you using - analog input/output, digital input output?

Why don't you make things simple for the people trying to help and post your code?

[Vamp]

I have attached my code and I apologize; it was the instrument I/O assistant I was having the problems with. The parameters are numbers being sent to a DSP to identify pulse widths and delay times.

[TobyHex]

Vamp,

I just wanted to check and see how you are aware what the Instrument I/O sends each time this command is run? You mention that if you open the express VI again, and reconfigure it, that it works just fine. How do you know it works? In the same regards, how do you know it does not and what is being sent in when it does not work? Do you have the Session In configured for the correct port?

Thanks again

Nick

[Vamp]

TobyHex,

I am sending lengths of time to a DSP, the DSP has a C++ program on it that takes the values I am sending it and creates a waveform. The first thing it expects tells it how many pulses, p2 is for two pulses and p3 is for 3 pulses. The very next thing it expects is a delay time until the signal is suppose to go to a high state, after that it wants the time when the pulse goes low, and then when the pulse goes high again... this alternates between the high and low state for the number of pulses that I want it to generate and then the final value is an off delay time(this one doesn't really affect the waveform). These values are sent all in one line of code; example "p3 0.1 0.2 0.3 0.4 0.5 0.6 0.7". All of the times are with respect to the start time, so it pulses three times with pulse widths of 0.1 seconds in this example. I have another I/O assistant send a trigger command "t". This simply tells the DSP when to generate the pulses. I am observing this waveform on an oscilloscope. So I can tell when it does not work or when it does. After the first line of code has been sent to the DSP, I can trigger the DSP to generate the pulses as many times as I want using only the "t" command. The waveform does not change on the oscilloscope when running the program as a whole... I can tell that the scope does trigger on a newly generated waveform. So the trigger part is working, it just isn't changing the waveform. 

[TobyHex]

I was reading through your posts and something stuck out to me. You mention in your first post that it doesn't always read in the new parameters. Does this mean that sometimes it does read in the parameters passed in by the controls? If so, what is the difference when you run this VI compared to the first time? Are you running it as a subvi and not passing parameters in? Is this the whole code or is there a larger set to it? If so can you post how you call this VI?

Thanks

Nick

[Vamp]

I have used the I/O assistant many times in both subvi's and in the main program. I don't believe any of the subvi's that I created used numbers outside of the subvi for the I/O assistant. This particular one is not a subvi, It is a main program. It seemed to work fine for a long time when I was just sending the two pulse (p2) that I spoke of earlier. When I changed it to the three pulse (p3) it started acting up. If my memory serves me right, when I was running the program and the numbers that were being fed into it was not being used, I could open the I/O assistant and the new numbers would be entered even though they were not actually sent to the DSP, close it with the ok button, without changing anything, and run the program as a whole again and then it would work. Currently there are other tests being done with the DSP, so I can not double check what I just wrote...but as soon as I can I will verify. It seems like it is something to do with the software, I have had this problem when trying to talk to other instruments as well, could not figure out what was going on, and just avoided using the particular command that wouldn't work in the program as a whole. I appreciate your help so far hopefully we can figure this out.

Thanks,

[Scott-M]

Hi Vamp,

Another step that might help us locate the issue, is doing a NI Spy capture, this is a program the monitors driver calls and tells you exactly what is being sent out to the instrument, it might help us narrow down where the incorrect command is coming from.

Performing a Good NI Spy Capture for Debugging/Troubleshooting

let us know what you find in your test.

Thanks

Scott M.