Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Oven control

I am trying to control 5 heaters independently through PWM of stand alone SSRs with feedback from five sensors (RTD or Thermocouple) and need to detemine which modules I need with a Cdaq. I have a cdaq 9172, modules ni9211, ni9472, ni9485, and ni9481 from a previous job that I was hoping to use. My thought was to use the 9472 to modulate the standalone ssr's based on the temperatures read from the 9211.  As I wrote the code and began testing/invetigating I ran into some problems. I'm not sure the cdaq can support 5 seperate PWMs and am thinking the 9211 is slowing the system down.  Can anyone offer any input? 

 

 

0 Kudos
Message 1 of 15
(7,855 Views)

The 9172 only has two counters on the backplane.  With your current hardware I would suggest something like this...

 

Use the 9472 (in slot 1, 2, 3, or 4 of the 9172) to run a clocked digital output task to generate the PWMs as in this example:

https://decibel.ni.com/content/docs/DOC-8010

 

There is no dedicated digital output sample timing engine on the 9172, so I would suggest generating the clock using a counter output task.  The internal counter will be named "<chassis_name>/_ctrN" and the terminal to use for the sample clock will be named "/<chassis_name>/CtrNInternalOutput" where <chassis_name> is the name of your 9172 and N is the counter number (0 or 1).

 

Use the 9211 as a software-timed analog input task and write the new duty cycles to your digital task based on the measured values.  It is indeed a very slow module.  

 

How fast does your control loop need to run?  Possibly for temperature control a couple Hz is enough, but if not you might want to look at a different analog module (e.g. 9213 is somewhat faster).  Of course, there will be an inherent latency due to the buffering of the digital output task, and the control loop isn't going to run much faster than ~10s of Hz anyway due to bus latency using cDAQ platform.  If you need an exceptionally tight temperature control loop then you'd probably want to look into replacing your 9172 with a cRIO.

 

 

Best Regards,

John Passiak
0 Kudos
Message 2 of 15
(7,822 Views)

John,

 

Thanks for the response.   Do you happen to have an example of the generating a clock using an output task?  I'm a little confused as to how this is wired to the sample u suggeted and the clock generation.  

 

 

In so far as the speed of the control loop, we are at too early of a stage to say.  I am hoping that a low frequency will sufice. We have a realtivly large thermal mass that we are contorlling.

 

Thanks again,

 

Chris

0 Kudos
Message 3 of 15
(7,805 Views)

Just run a continuous counter output task, for example:

https://decibel.ni.com/content/docs/DOC-25157

 

To specify the internal counter, use "<chassis_name>/_ctrN".

 

Don't define the counter output terminal like the example shows.  Instead, on the digital output task specify to use the counter's internal output ("/<chassis_name>/CtrNInternalOutput") as the sample clock source.  Keep the counter task running while you are running your digital output task.

 

 

By default these internal counter and terminal names are hidden in the DAQmx LabVIEW controls (it's rather annoying to be honest).  You can still type them in manually or you can change the I/O filtering options to get them to show up.

 

 

Best Regards,

John Passiak
0 Kudos
Message 4 of 15
(7,792 Views)

The continuous counter example is in Ver 2012.  Any way it could be saved Ver 2011 and repost.

 

It's taken a while but I did find how to "unhide" terminal names.  Thanks.  Still getting error:

 

"Some or all of the samples to write could not be written to the buffer yet. More space will free up as samples currently in the buffer are generated.

To wait for more space to become available, use a longer write timeout. To make the space available sooner, increase the sample rate.

Property: RelativeTo
Corresponding Value: Current Write Position
Property: Offset
Corresponding Value: 0"

 

Thank for all your help

0 Kudos
Message 5 of 15
(7,785 Views)

Here's an older version of a similar example:

https://decibel.ni.com/content/docs/DOC-12164

 

You would get that error if you never received any sample clock edges, which I think is probably the most likely cause since you are still trying to get the sample clock set up.  Can you post a screenshot of your VI?

 

 

Best Regards,

John Passiak
0 Kudos
Message 6 of 15
(7,782 Views)

Capture.JPG

Any feedback woulfd be help ful

0 Kudos
Message 7 of 15
(7,752 Views)

Change that task you have posted to a digital output task.

 

Run a second task (counter output) at the same time as the digital output task to generate the clock signal.  This programming for the second task would look like this.

 

If you set the sample clock source for the digital output as I have mentioned previously, then the digital output will be clocked by the counter output.

 

 

 

Best Regards,

John Passiak
0 Kudos
Message 8 of 15
(7,745 Views)

John,

 

I sense your frustration but really appreciate your patience.

 

I tried what you suggest  and the 9472 DIO4 began to flash.  Then I got this error.  Any suggestions

Capture.JPG

0 Kudos
Message 9 of 15
(7,733 Views)

Sorry it came across that way, I don't mind at all.

 

You're really close--the problem is that the digital output task is writing a buffer of 500 samples but the counter task is only generating at 1 Hz.  So once the buffer is full it would take 500 seconds for space to become available (and the default write timeout I believe is 10 seconds... but you don't want your program blocking this long anyway probably).

 

You'll likely want your counter output to run much faster than 1 Hz (a higher frequency will give you more resolution on your PWM).  Pick an appropriate buffer size depending on the sample rate you choose--a larger buffer will make the program more robust in terms of avoiding underflow but will increase the control loop time.

 

 

Best Regards,

John Passiak
0 Kudos
Message 10 of 15
(7,729 Views)