andymatter

QUOTE (fuqface @ May 13 2009, 06:46 PM) Assuming the DO channel is working properly (5V when open-circuit) and not configured as open-collector (I don't know if the 6009 can do that), it sounds like the pump-trigger circuit is drawing more current than the DO can source. Check the specs for both. When talking about using DO lines to drive various loads, it's not a question of increasing the voltage of the logic circuit itself in order to get more juice to your load (logic supplies aren't generally meant to be adjustable), but of putting the proper drive circuit in between to keep both source and load operating currents within their intended specs, so that you're less likely to cause damage or unexpected behavior in either of them. Can you describe for us the pump-trigger circuit you're trying to drive? (i.e. relay coil, transistor, optoisolator, trained chimp holding two wires, etc.) QUOTE (Karissap @ May 13 2009, 09:56 PM) Have you tried using the analog output channel set at 5V instead? Assuming it's a current sourcing problem, I don't think I would try that. The specs for the 6009 say that the max current capability is 5mA for an AO channel and 8.5mA for a DO channel, so you probably need more than 8.5mA, assuming you haven't already reduced your available current below 8.5mA by using up your total DIO current-drive allotment of 102mA in your other DIO channels.

QUOTE (orko @ Feb 20 2009, 11:46 PM) Oooh, .NET you say... It wouldn't happen to be Cypress Semiconductor's CyUSB driver, would it? That's the one I'm currently using. It works perfectly in LabVIEW if you're not doing sustained high-bandwith transfers (even though the driver was designed to do so). Setting everything up and transferring data using their simple XferData() method is pretty easy. I could even share a quick n' dirty example with you if you're interested. The problem I ran into, however, was when it was discovered that the device we (me & the company I work for) are building needs to output data faster than can be transferred using the XferData() method. CyUSB does provide more advanced methods for performing overlapped (asynchronous) transfers needed for higher-bandwidth streaming. Cypress' C# examples that come with the driver in the free SuiteUSB.NET 2.0 package use these methods and work just fine. The situation gets ugly when you attempt to call these advanced transfer methods in LabVIEW. I spent a LONG time trying to figure out what is causing these methods to fail in LabVIEW, but I wasn't able to figure it out, as the problem appears to be somewhere between LabVIEW and Windows. I couldn't figure out how to troubleshoot that sort of thing (advice?). I'm currently attempting to wrap up all my high-speed transfers using the advanced methods into a DLL, so as to keep them in their native .NET world when I want to use them. So far, my DLL crashes LabVIEW. Yeehaw. If you're not using CyUSB, then may I ask what driver it is? What does it cost? Does it provide data-tranfer methods that break up a transfer into its separate parts (i.e. something like BeginTransfer(), WaitForTransferCompleteCallback(), FinishTransfer())? I eagerly, droolingly await your reply.

It sounds like something is causing VISA to reset EP4. You *should* be able to request data from the endpoint at this time, so it sounds weird to me that transfers won't work. Have you tried opening duplicate VISA sessions, each dedicated to a single endpoint instead of switching between each of them in one session? I'm currently mucking around with USB and LabVIEW using a third-party driver. I actually haven't used NI's VISA USB. After I started reading about it and asked NI a few questions, I was frightened away by its lack of features, unclear functionality and jargon that doesn't completely follow that of the USB world. But, hey, don't let me scare you away from it. I would be very interested in hearing about your successes/failures. As long as you're not hoping to stream huge gobs of data in real time, I'm sure you can get VISA to behave.

QUOTE (shoneill @ Dec 10 2008, 03:03 AM) The endpoint is BULK and the direction is IN. I have just read through the help files for all of the VISA functions and properties relevant to USB Instr and USB Raw and I don't see anything suggestive of different USB transfer modes as I've defined them above. Am I missing something? QUOTE (shoneill @ Dec 10 2008, 03:03 AM) If you're using something other than BULK transfers, things would be a little more interesting. For Interrupt transfery for example you can create more than one listener so that when one listener is busy processing data, others are still actively monitoring the USB port. Asynchronous transfers are, by nature, multi-listener, where each "listener" in the queue is an event callback from the OS. The endpoint can also be BULK or ISOCHRONOUS type, not just INTERRUPT, but I see now that you're speaking specifically of NI-VISA's implementation. Hmmm. I see that there is no specific event "handle" passed between the "VISA Enable Event" and "VISA Wait on Event" functions, suggesting that an individual VISA event is a blocking task. That is, it would suggest that one can't fire off a queue of events and then wait for each specific one to roll in, all within the same thread. That means I would have to divide the task into separate threads, where I'm limited to my remaining unused execution systems * 2 threads per execution system = 8 to 10 threads. Is that enough? Does VISA even allow this sort of multiple-access to the same USB device endpoint? It might be do-able. [whine] I was hoping to stay lazy and use a BULK endpoint of the USB chip's built-in Default Device, but to give me an INTERRUPT endpoint with a decent buffer depth requires that I write a buttload of firmware first [/whine]. Thanks for the link to the tutorial. It was interesting, but I didn't see anything that addresses this specific issue. Again, I may have missed something.

Hi all, Question for the USB programmers: I am currently attempting to write a LabVIEW application in Windows using a third-party USB driver to communicate with a custom device. The driver's provisions for asynchronous I/O have been giving me grief for a while now, so I am checking out alternatives. I need a driver that will allow me to perform high-speed data transfers over a bulk endpoint. Let me stop to define terms here, just so we're all on the same page... There are basically two approaches USB data transfers: Synchronous (blocking) This is the easy way of doing things, where you issue an I/O request, wait for the data to transfer within a certain timeout and then return your results (data, bytes transferred, success, etc.). Note that there is nothing happening on the bus over the time interval where the transfer bus-signalling has completed, the interrupt is serviced by the OS, the OS signals a transfer-complete event to your waiting function, you process the results of the transfer and call your function again in order to issue the next I/O request over the bus. That time interval represents a huge waste of bus bandwidth and, while this method allows for enough movement of data for most applications, it does not work if you need to move large amounts of data in the shortest possible time. Asynchronous (non-blocking) This is where you set up a queue of transfers to make better use of the bus. Basically, you start by issuing a queue-full of I/O requests, service the results of each item as they come in one by one, re-submitting each item back into the queue by issuing another I/O request. This way, the next transfer is always coming in over the bus while you deal with the results of the previous transfer. I've read Windows driver programmers call this "overlapped I/O". This is how sustained high-speed transfers are done. I'm looking for a driver that provides for an implementation of the latter. I've been looking all over the internet for a generic Windows USB driver that will do the trick, but so far I am unimpressed with the advertised capability and/or cost of what I've found. I know that LabVIEW provides VISA functions for USB and that any device can be set up to use them. Is it possible to use VISA events in a way that will allow me to do fast queued asynchronous I/O over USB? If so, does anyone have an example? Is this beyond VISA's capabilities? What are your experiences? Any suggestions? I would really like to avoid writing my own Windows drivers or starting over from scratch under Linux. ...As an aside, has anyone successfully used the asynchronous transfer methods of Cypress Semiconductor's CyUSB driver in LabVIEW?

:worship: Wow. Thanks for all the great ideas! I haven't used external code before now, so this facet of LabVIEW is new to me, along with all the memory-management considerations. I have already tried using the easy synchronous XferData() method, but the resulting data throughput wasn't satisfactory, so that's why I'm heading in the more complicated route. I really like your idea of calling this method in multiple reentrant instances (and I'll try it), but there is talk of changing our data (USB) endpoint from a bulk type to an isochronous one, meaning that I may be stuck with the asynchronous Begin/WaitFor/Finish methods. Oh well, I'll get there one way or another.

Hi, I'm using a third-party USB driver in the form of a .NET assembly DLL to talk to an instrument we are building. The driver's documentation provides a C# example for implementing data transfers that make the best use of available bandwidth on the USB. I am attempting to duplicate the example's functionality in LabVIEW, but this involves an oddball pointer type conversion that does not seem to translate very well into the LabVIEW paradigm (i.e. I've tried everything I can think of, but I can't figure it out). The specifics are as follows: The driver provides Begin/WaitFor/Finish-transfer methods that all require an array of event-references(?) to be passed between them. This array is a 1D array of 20 bytes. In the C# example I'm working from, the event-reference is written-to/read-from the array through a struct object provided by the driver. The struct serves as a "map" to expose the byte array as a set of U32 values that I can get/set through a .NET Property Node. 1) How do I reference the array through the struct object in LabVIEW? See the contents of the ZIP file. Alternatively, I could avoid using the struct object altogether in LabVIEW by simply using the Type Cast function for the bytes[]/U32/reference conversion. The problem with this, however, is that I'm not entirely sure which 4 bytes represents which U32 value or what order the bytes are in. In order to find out for sure on my own, I need question #1 answered, so I can set a value and see how the array changes. Otherwise, if I can't use the struct object, can someone tell me... 2) Given the info provided, where in the array can I assume the "hEvent" struct member to be (and its byte order)? If anyone could point me in the right direction, it would be much appreciated. Thanks.