The Sticky Motor

[MogaRaghu]

I have a very funny bug (?). In the snippet that is attached when the condition for the two case structures become TRUE, I am switching off a 22KW motor output bit , writing it to a DAQMX write function and going to the next case. 3 out of 10 times the motor does not switch off, leading to a messed up machine sequence. I am sure that I am transiting to the next case as the Message string changes as expected. In fact this can only happen if the QSM changes over before the output cluster gets written to. But I am sure this cannot happen as both have to update in the same case??

What can be wrong in such a situation that the DAQMX write failes to refresh at times ? And being a random faultr i am unable to devise any error trap.  Going nuts over the issue. Any tips ?? Or is there is any fundamental flaw in the approach ?? ( The TimedLoop runs at 10ms with  no "Finished Late" warning ).

Thanks

[johnsold]

I do not see anything in the image you posted.  Neither the DAQmx Write and the message string you mentioned seem to be in the image.

Is it possible that the DAQmx Write occurs and then another write happens so quickly that  the motor does not notice?

Lynn

[Wayne.C]

Which DAQ device are you using?

[MogaRaghu]

Which DAQ device am I using ?

Its a combination of PCI - 6514 for DIO and PCI-6229 for AIO. And due to shortage of IOs on 6514, I am using 1 byte of 6229 for DO.

Of course there many individual DAQMX tasks defined and I am not too sure if there is any limitation or recommendations on the way one groups physical channels into tasks. Trying to read more on that. The problem that I have, seems to be at that level as the 6514 DIOs are split into atleast four different tasks and the physical number of IO pins are not contiguous in each task. In my code there is a possibility that two or more tasks can try to invoke the DAQMX Write functions and hence I have created a data dependency by using the error data wire.

[MogaRaghu]

Some more on  the Tasks as  assigned.

the code is for controlling 4 identical rigs and the task assigned are as follows :

While sequence is same for all rigs, there is no synchronisation as such. And at any given time each rig could be in a different state of the sequence based on field variables.

For instance, when I try to switch off P4.0=22KW motor of RigA, it is possible that P4.1=22KW motor of RigB is required to run. Would like to know if there is anything fundamentally wrong in this kind of task assigning. (I can instead re-assign 1 byte for each Rig.) Would this help to solve the problem?

Task_RIG_A

P4.0 = 22KW motor

P4.4 = 2.2KW motor

P6.0 = PFM solenoid

P6.4 = Accumulator Solenoid

P5.0 = PT solenoid

P5.4 = DUT solenoid

P7.0 = Part Solenoid

P7.4 = Watrer Solenoid

Task_RIG_B

P4.1 = 22KW motor

P4.5 = 2.2KW motor

P6.1 = PFM solenoid

P6.5 = Accumulator Solenoid

P5.1 = PT solenoid

P5.5 = DUT solenoid

P7.1 = Part Solenoid

P7.5 = Watrer Solenoid

Task_RIG_C

P4.2 = 22KW motor

P4.6 = 2.2KW motor

P6.2 = PFM solenoid

P6.6 = Accumulator Solenoid

P5.2 = PT solenoid

P5.6 = DUT solenoid

P7.2 = Part Solenoid

P7.6 = Watrer Solenoid

Task_RIG_D

P4.3 = 22KW motor

P4.7 = 2.2KW motor

P6.3 = PFM solenoid

P6.7 = Accumulator Solenoid

P5.3 = PT solenoid

P5.7 = DUT solenoid

P7.3 = Part Solenoid

P7.7 = Watrer Solenoid

[Wayne.C]

Raghunathan,

I'm pretty sure that multiple DO tasks is the problem.  Only one DO task can be running at the same time and that might explain things acting strange.  You should try putting all PCI-6514 DO's in same task.  Just curious, did you setup all your tasks in MAX or did you create them programatically?

[Dennis_Knutson]

Actually, you can have multiple DO tasks if they are static writes. Since the OP has not posted any code or even a real snippet, impossible to say how the digital I/O is being used.

[MogaRaghu]

---

@Dennis Knutson wrote:

Actually, you can have multiple DO tasks if they are static writes. Since the OP has not posted any code or even a real snippet, impossible to say how the digital I/O is being used.

---

I write to the DAQMX Write function once every 10ms when the Timed Loop fires. Unfortunatley this code is quite large and still in testing phase and I am unable to post the code in detail.

I have attached a snippet that shows how the DAQMX writes are aligned. And if you notice there is a rather odd way of getting the Task Ref. It is from a FG that gets written in MAIN. The reason for this : The whole code contains many sub-VIs which are dynamically called from MAIN and not all of them need all DIOs. Reason why so many tasks were created.

And for now ( to overcome  the problem I have ) I am trying to merge all the DO  Tasks  into a single task and build a single 32bit boolean state array from the 4 different bytes of the 4 rigs. Let me see if this will solve the problem.

[MogaRaghu]

---

@Wayne.C wrote:

Raghunathan,

I'm pretty sure that multiple DO tasks is the problem.  Only one DO task can be running at the same time and that might explain things acting strange.  You should try putting all PCI-6514 DO's in same task.  Just curious, did you setup all your tasks in MAX or did you create them programatically?

---

Created all the Tasks programatically in the MAIN and wrote the task references to a Functional Global. After this whenever a Sub_VI is called, it only reads the required Task ( for it to function ) from the  FG. Reason why so many tasks were created.  

[MogaRaghu]

Tried to reduce the number of Tasks to a single one and this did not help at all. The problem remained.

The problem finally boiled down to the fact that PCI-6514 card's output bit ( 4.x to 7.x) was not resetting to Zero volts when switched OFF. The data sheet says the low state can be between 0 to 4V and in my case it was anywhere between 6 to 10V. Thus the interface relays could not switch OFF as they all have a switch ON voltage of around 18V and holding voltage of less than 10V.

As  a last resort I had to use the spare digital outputs of the PCI-6229 card which was being used for AI, level translate them to 24V and [AND] them with the PCI-6514 outputs controlling the motor relays. Not very elegant but a solution that worked for sure.