Duty Cycle Update Issues

[arcranda]

I am using a counter generated by a PCI-6110 to switch a solid state relay that turns a heater on and off. I'm updating the duty cycle based on the output of a PID controller (the 0 - 100 output of the PID VI gets scaled to a duty cycle of 0.001 to 0.99). The issue is after two iterations the property node no longer writes the scaled PID output to the task and it seems to default to 0.

A lot of the counter generation examples use  event structures to detect a change in duty cycle and pass that on to the task. But do event structures detect changes in values if the value is written to a local variable and not typed into a numerical control? I feel like the answer should be 'Yes'...but in cases I've tested it seems to be 'No'.  

Does adjusting the precision of a numerical indicator/control limit the number of significant digits a calculation carries? I'd like to limit my duty cycle to 2 decimal places - i.e. 0.3342 and 0.3313 would both be 0.33. That way the duty cycle isn't being unnecessarily updated. 

The temperature is being read by a PCI-4351...which may show up as ? blocks if you don't have those drivers installed.

[tbob · Accepted solution]

---

@arcranda wrote:

A lot of the counter generation examples use  event structures to detect a change in duty cycle and pass that on to the task. But do event structures detect changes in values if the value is written to a local variable and not typed into a numerical control? .

---

To have an event fired when a value changes programatically, create a Value(signaling) property node and wire the new value to it.  This will trigger a value change event for that variable.

---

@arcranda wrote:

Does adjusting the precision of a numerical indicator/control limit the number of significant digits a calculation carries? I'd like to limit my duty cycle to 2 decimal places - i.e. 0.3342 and 0.3313 would both be 0.33. That way the duty cycle isn't being unnecessarily updated. 

.

---

Changing the display properties to show only 2 decimal places does not change the numeric value stored in memory.  You would have to round off the numeric to two decimal places.  One way to do this is to multiply the number by 100, change it to an integer (this will lose the remaining decimal places), then divide the result by 100 to get two decimal places again.  When changing to an integer, you will need to round off to nearest integer so that 0.3299 will become 0.33.

[arcranda]

Thanks, tbob. Rounding the duty cycle and using an event structure did the trick. I would have never come up with the Value change (signaling) property if you hadn't mentioned it. 

"Solution" code is attached.The rounding is done in PIDtoPWM.vi

-Andrew

[tbob]

In your PIDtoPWM vi, where you round off, you are checking to see if the value is zero.  NEVER use the equal function to test a floating point number.  The number will almost never be exactly zero.  A zero may be represented as 0.0000000000001, which will fail the equality check.  This is because computers cannot accurately store a floating point number.  Instead of using equal, use the InRange and Coerce function, and set the upper limit to 0.0001 and lower limit to -0.0001.  This will do a better job.

[arcranda]

Gotcha. Thanks for the catch 

PIDtoPWM.vi with =0 replaced with In Range/Coerce attached.