PULSE vs. SEND_COMMAND 'SPxx' for IR

GasHed

What is the technical difference between using these two methods to pulse an IR command? Advantages/disadvantages to each?

champ

SEND_COMMAND dvIR, 'SP??'
will queue up three pulses whereas
PULSE[dvIR,??]
doesn't, so you have to create a stack, timeline or nest waits to use it for lots of pulses.

I queue commands in a stack and empty it using SEND_COMMAND dvIR, 'SP??'
just in case my timing is a little quick.

The down side of SEND_COMMAND dvIR, 'SP??' is it has become unreliable in recent firmware updates, so I now have a flag which is used to switch between PULSE and 'SP' when things go weird. I change this flag in a tech page which the user doesn't know about.

DHawthorne

SP allows you to use the CTON and CTOFF command on the IR port to adjust timing individually, and once and for all for each port. PULSE requires the SET_PULSE_TIME keyword, which is global, so you have to use it constantly when you switch devices if they are not all the same. It also applies to relays and anything that can be pulsed, and can get convoluted to track if you keep needing to change it for various devices.

GasHed

champ,

You are getting at what prompted me ask the question. I have an NI-3000 with IRL files loaded and it seems that the SEND_COMMAND works sometimes... I switched to PULSE and it works more consistantly/always, but obviously I'd like to be able to take advantage of the SEND_COMMAND queueing.

Pat

ipssheldon

If you have IR issues with the SP command, I have found a fairly reliable solution in the NI-series masters. Roll back to Rev 115 fo the devices firmware (send to device 5001 not the master) an in almost all cases, the SP commands start working again. I think Rev 115 has its own issues with IR slots above 95 or so, in case you build your IR files for multiple devices (share IR emitters on a single port). But it seems to work well if each port controls a single device. On the last 4 or 5 NI-series installs, I have done this and it solved all IR problems instantly.

SP commands allow the processor manage all of your IR timing, using the CTON and CTOF commands via a DATA_EVENT. Much easier way to code, when it works.

Just a thought.

Sheldon Samuels

GSLogic

There is an update to the NI series for the SP problem, anything after version .118 is supposed to of fixed the SP problems.

DHawthorne

GSLogic wrote:

There is an update to the NI series for the SP problem, anything after version .118 is supposed to of fixed the SP problems.

There has been some question as to whether the new revision broke the CH and XCH functions; the jury was still out last I heard. I'm sticking with 115 until I know for sure, the 118 fiasco cost me days of frustrated service calls.