Jump to content

As of July 17, 2015, the LabJack forums here at forums.labjack.com are shut down. New registrations, topics, and replies are disabled. All forums are in a read-only state for archive purposes.

Please visit our current forums at labjack.com/forums to view and make new posts. To post on the current forums, use your labjack.com login account. Your old LabJack forums login credentials have been retired. There are no longer separate logins for labjack.com and LabJack forums.


Photo

Do I need to read the response using the Exodriver


  • Please log in to reply
5 replies to this topic

#1 Iandol

Iandol
  • Members
  • 46 posts

Posted 11 February 2011 - 07:52 AM

Hi, I always read the response of the LabJack after writing to it (exodriver via Matlab). In many cases, I just throw the response away and never really error check. If so, do I even need to read the response; can I just ignore it?

% ===================================================================
%> @brief Turn LED ON
%>	
%>	
% ===================================================================
function ledON(obj)
	if obj.silentMode == 0 && obj.vHandle == 1
		obj.rawWrite(obj.ledIsON);
		in = obj.rawRead(obj.inp,10);
	end
end


#2 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 11 February 2011 - 10:57 AM

You do need to read the responses. Communications are done through a command/response structure, unless you are using stream mode. I believe on the UE9, U3, and U6 if you perform two consecutive writes without reading the responses the device will reset itself.

#3 Iandol

Iandol
  • Members
  • 46 posts

Posted 01 August 2012 - 02:43 AM

You do need to read the responses. Communications are done through a command/response structure, unless you are using stream mode. I believe on the UE9, U3, and U6 if you perform two consecutive writes without reading the responses the device will reset itself.


I have a new function which I want to send asynchronously, in this case a digital TTL high of variable length.

line = 1; %FIO1
time1 = 100; % 16e-3 * 100 = 1.6s
time2 = 100; % 64e-3 * 100 = 0.0064s

cmd=zeros(16,1);
cmd(2) = 248; %command byte for feedback command (f8 in hex)
cmd(3) = (length(cmd)-6)/2;

cmd(8) = 11; %BitStateWrite: IOType=11
cmd(9) = line+128; %add 128 as bit 7 sets value high

cmd(10) = 6; %IOType for waitshort is 5, waitlong is 6
cmd(11) = time1; %time to wait in unit multiples
					
cmd(12) = 5; %IOType for waitshort is 5, waitlong is 6
cmd(13) = time2; %time to wait in unit multiples

cmd(14) = 11; %BitStateWrite: IOType=11
cmd(15) = line; %bit to set low

obj.command = obj.checksum(cmd,'extended');
obj.outp = obj.rawWrite(obj.command);
obj.inp = obj.rawRead(zeros(1,10),10);


If I have to read the response (obj.rawRead calls LJUSB_Read directly) then Matlab blocks for the length of the TTL (1.6064 second TTL and Matlab hangs for that time). If I comment out the obj.rawRead then Matlab returns directly. If I keep doing this without reading I don't notice a reset (tested on a U6, is the reset very fast?), but perhaps over time things get worse?

What would happen if I use the new LJUSB_WriteTO commands with a small timeout, does a timed out read handle differently? I suspect it won't because what is blocking is the previous obj.rawWrite command and until the WaitShort and WaitLong feedback commands complete the LabJack will not respond to the obj.rawRead...

Is there a way to not let the LabJack reset itself (not that I notice it) and handle unread responses gracefully?

#4 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 01 August 2012 - 02:22 PM

The reset is fast, and is a soft reset (no re-enumeration). It will mainly clear buffers on the U6, and you will probably not notice it. Using LJUSB_WriteTO will not affect the timed out read differently unless the write timed out before it was able to send the command. A WaitShort/Long Feedback command can cause a following response read to timeout/fail because your U6 has not provided a response yet. If your read does not get the response, you can continue to perform reads until you do get one. Also, since you know what the additional response delay is going to be you can throw in a delay/sleep in your program between the write and read.

#5 Iandol

Iandol
  • Members
  • 46 posts

Posted 02 August 2012 - 03:59 AM

The reset is fast, and is a soft reset (no re-enumeration). It will mainly clear buffers on the U6, and you will probably not notice it.


So for asynchronous mode I will basically not read and let the reset occur -- have you timed how long the reset takes, and does it occur on the next write i.e.

write 1
(reset)write 2

or after some defined timeout with no read

write 1 ...deltatT... (reset)
write 2

Thanks!

#6 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 06 August 2012 - 11:52 AM

The reset will occur when a command is received and the previous result has not been read. Be wary as constantly reset the USB pipes may lead to problems. It would be much better to do your long timing PC side or extend the time out.


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users