Problem with HW sampling mode for a PID cycle

[Principiant]

Dear all,

I`m almost sure someone of you can help me as the last time to understand what`s wrong with my application (see attachment).

I expose my aim. I have a device which through a PCi Card gives me some data. This data can be read from the VI data source as DBL single as You can see in the Block diagramm.

The Idea is to make a PID loop which has in input these data and as error signal produces a voltage provided from an USB-6259 BNC.

Well for the moment I want only to see if I`m able to make the card reproducing the signal in input as you can see, so I avoided a PID elaboration of the input signal.

Using a Continuous mode sampling generates a buffer error so, following the examples I tried to use an HW mode which doesn`t save data in the buffer. But it doesn`t like it also and an error of connection appears:

(error -200077 of properties node. suggestions: change in continuous or finte number mode)

and I have simply reproduced the example!

The only way I can get something is using the example "PID Single channel Alternative" where the timing of the writing task is not set and set the sampling mode of the reading task  as contiuous. But in this way the minimal sampling frequency stays at 1000 Hz where I would need at least 10 times so much to have a good sampling of the input.

And furthermore I have no way to make the input signal read from an analog input port of the card.

Is there a possibility to create a PID with sampling rate at least 100 kHz?

Where comes from the error?

I will be grateful to everyone can give me an hint.

Greetings

Principiant

[Stuart_G]

Here is my last reply regarding HWTSP (what the example you mention is doing).  I know I have had other posts regarding PID and HWTSP.

"

Significance of HWTSP.  This is used primarily in control applications where low jitter and speed are crucial.  Every point is important to the PID calculation you are doing.  We have put a lot of optimizations into this mode so that the Reads are more efficient and there is lower jitter simply because the buffer size is 1.  For most control apps I would say this is the way to go.  The downside is you are not going to be able to monitor as fast as a buffered acquisition.  If you use LabVIEW RT it can help increase the speed degradation but Windows is so jittery that this mode will error at moderate rates.  I hope this makes sense??"

If you truly want this type of application 100KHz is not going to be possible.  I would say on Windows the best you will get is 20kHz.  On a fully optimized RT controller you might be able to get 80k, and of course you are using SW timed AO.  I am also confused why when you set the mode to continuous that the maximum frequency you get is 1KHz.  Do you get an error if you set it higher?  Also, you are using USB for your AO which in general is a high latency bus and can skew results of PID calculations.  Now, I don't know what your control is so that might be acceptable.

StuartG

[Principiant]

Hi Stuart,

Thank you very much for your efforts, perhaps is better I `ll explain me better, the fact is taht I have made so many trials and changes that was difficult to summarize where exactly the problem is located. I need a PID that is able at least to run 1000 Hz.

Short to say: it is not possible for me until now to make the card working in the Hardware Timing sample mode. Each time I try to select it the error above pop up saying "the value seleted for the timing property is not supported." and suggests me thereafter to change in continuously or limited number of value timing. Could be that this kind of timing is not supported from the USB?

Now one could think then to change to continuously acquisition but then another error appears saying the Buffer size is "only 1 when at least 2 would be needed" and until now I didn`t suceed to make it changing idea even when I set the sample pro channel 1000 or I try to use the buffer property node.

The first way I got something out was to include the data output in a for cycle and produce so an array of double values of limited length but in this way I loose the PID synchronization.

A second way was using a vi similar to the one I attached in this message. So keeping the writing task not timed (but then I need a timed read task) I ´m able to make it writing directly single samples double format . The problem here is that the writing sampling can`t go below 1 ms whatever fast the reading sampling is. This forces to keep the reading sampling to 1000 Hz also.

The only way to make it faster would be to select explicitely the sampling frequency for the writing but in this way I have to place a timing Vi on the write task and this again produce the buffer error I explained above.

 Now I`m asking myself if someone has never done a PID with such a card, if it is possible, and which wuld be then the maximum frequency (if 20 000 would be more than enough).

If you or someone else could help me to understand where the misunderstandig stays I will be very grateful indeed.

bye

Principiant

[Stuart_G]

I think I assumed from your first post when you said "I have a PCI device..." that you mean an NI-DAQ product.  However, I am guessing now that is incorrect.  The only NI device you have is the USB device.  In which case the error you are getting with the Hardware Timed Single Point is in fact because USB devices do not support that mode.  Mostly because USB is a horrible bus to do control in.  If you use continuous mode you have to specify number of samples per channel to be 2 samples.  However, you still should be able to read one sample at a time if that is what you desire.

I'm sure PID has been done with these cards, but there will be issues.  I expect that 1KHz is achievable.  I would setup continuous, sample clock timing (number of samples per channel to be whatever 1000 should be fine) for both of these, read one sample, do your calculation, and then do a write.

Use the PID Control-Single Channel VI.  The only change you will need to make is change from HWTSP to continuous on both the AI and AO tasks.  Also, get rid of the "wait for next sample clock VI" .  It won't do you any good with continuous mode.  Should work after that.

In order to achieve 1k with USB on Windows you MIGHT also have to set your VI to time critical priority, but I wouldn't start there.

StuartG

[Principiant]

Hi Stuart,

Yes you are right the PCI device is not a National Instruments device, sorry I have not expressed me well.

Anyway I followed yor suggestion ( I`m sure I already tried it but I repeated for safety). As you can Imagine if i try to use the example changing only the sample mode and removing the "Wait for sample cloks" Vi it repeats the same error " the buffer should be at least 2".

So I have to create an array of at least 2 samples in order to get out something. It is anyway hard to make it working properly (if it is possible), the results are by now not nice at all. 

I also called NI support to get informations. In addition to what you already confirmed and I suspected (USB do not support HW sampling) they also added that a PID could not be made in principle on not Real Time systems which sounds me a bit strange.

 Anyway I try now to make a simpler thing performing a PI action on a signal read from the USB 6259 card, using the same to output an error signal.

Here comes another problem when I try to use Shift registers on the while loop: "the card do not support unbuffered operations" something that I cannot relate with this apparently innocent change.

Anyway thanks for all your help, I hope that someone which has already made a PID loop with such a card read this thread and could give me an help.

Bye

Principiant 

[Stuart_G]

Can you send me a screen shot of your block diagram?  That might help.

StuartG

[Principiant]

Hi Stuart,

I want to say you that it seems the problem for the error I said you was not so critical, I went through (even if I really don`t know how).

But perhaps another question which could hlep me a lot in the next steps.

I haven`t until now understood how to make fitting sampling rate and number of sample pro channel to make the thing working at my selected frequency.

So to say until now everything works just playing around with not so much awarness of what is really happening. Very often two main errors appear: or the buffer has been overwritten and so data are lost or there`somehow a problem with slow communication between the parts of the setup.

Adding on it seems these errors are not deterministic. Sometimes when I start the program of acquisition let`s say 1000 rate and 10 samples for channel in reading task, it works smooth, other times (unpredictably) it crash on one of these two errors. Sometimes is enough to enlarge the buffer size some others it has no influence and some others even reducing the buffer size helps.

The only thing I discovered is that seems not advisable to make the input and output number of samples per channel different.

Have you a recipe to make the rate and the buffer size fitting together?

Thank you

Principiant