Best way to communicate with IEEE device

[Will.D]

Hi everyone;

I'm using a Magtrol DSP6001 Dynamometer Controller to control a dyno.  It's GPIB, and I'm able to communicate with it swimmingly, and I've used it it a number of other apps that I've written.

My problem now is, that I need to be reading the device as fast as possible, but at the same time, setting the torque at regular intervals.  Here's a better explaination:

I'm controlling a stepper motor (which is the main problem, as all the other motors I have written apps for using this equipment have been brushless servos) for an acceptance test, and part of the test requires that the torque be ramped up gradually until the motor starts missing steps, and the torque at which this happens is recorded.  The problem is, in order to accurately record the torque value, I need to be reading the device constantly (not a problem, as the controller is capable of providing 100 samples/second), but at the same time gradually increasing the torque.

You can see where the problem arises...  if I were to multi-thread this vi, then I would get randomly occurring IEEE errors, but if I have the data acquisition in the same loop as the torque increase, then I don't get nearly enough accuracy.  Is this something that a semephore would be useful for?  I have heard something about the IEEE bus being able to handle some sort of syncronization, but I don't know much about that...does anyone else?

Has anyone else had this sort of problem before?

Thanks, Geoff

Notes: I'm running the controller in open loop mode... for two reasons.  One, it's easier to have a smoother ramp in open loop by the nature of the commands used to communicate with it, and two, trying to obtain the PID settings for this motor was getting to be an absolute nightmare, and I don't think it worth the time, as it's just a ramp, not a constant torque.  Or am I wrong in thinking that?

[Will.D]

I have been toying with the semephores, but I'm either not using them properly, or it's not the best way to go.

If I let the data collection loop run 20 times for every time the torque loop runs, after each runs, since the loops are in parallel, I have no way of knowing which loop will acquire the semephore first, and thus couldn't be sure that they would run in the order I want them to...  But this could be because I'm not entirely familiar with them...

[tbob]

You can use GPIB.  In your loop, put a GPIB write command to send a new torque value, followed by a short pause, then a GPIB read command to get the data.  Put the data into a queue.  In a separate loop, read the queue.  If it is empty, do nothing.  If the queue has data, process it.  Your GPIB loop will run continuously and so will your queue read loop.  Data will only be processed when there is data to process.  This should allow you to run the GPIB loop fast enough.  You must put very small delays in each loop to allow the CPU to do other things and to allow the parallel loop to run also.

[Will.D]

Thanks for the reply, but I suppose I should have been more clear...  it doesn't exactly answer my question.

I have two loops, both of which need to communicate with the controller.  One loop (top in the image) I need to run several times faster than the bottom loop, as I need greater accuracy in the readings (more samples).

The bottom loop will run not as fast as possible - as the top loop will - but will run every say, 20 milliseconds.  You might be asking why that's not in the image, but that's just the bare bones of what I'm trying to do. 

I can't leave them to their own devices as is, since I'll get random GPIB errors because both might be trying to write at the same time, or one might write before the top has read, and then the read will return an error. 

I was just wondering what the best way to go about doing this is...  I'll try using queues to do this type of operation, sorta like you suggested.

Has anyone ever heard of GPIB being able to do synchronized communication?  (as in, is there a way to have two pieces of data, one being written and one being read, from the GPIB bus at the same time?  Like, being able to read what's been returned by the controller, but at the same time writing a new command to the bus?)

---

Message Edited by Novatron on 07-28-2005 03:49 PM

[tbob]

Instead of writing to the GPIB in the second loop, use the second loop to set a flag (boolean).  In the first loop, put the GPIB Write to set the torque in a case structure.  Create a local variable of the flag in the second loop and use this local as the input to the case structure in the first loop.  When the flag is set, the torque command will be sent either before or after the other GPIB write, wherever you place it.  Be sure to reset the flag in the same case.  If the flag is not set, nothing happens and no time is wasted.  This way there will be no clashing of GPIB writes.

[Dennis_Knutson]

Frankly, I didn't understand the problem because when in your first post, you said data acquisition, I thought one loop was doing GPIB and your were using data acquisition via a DAQ board in the other loop. I think your problem can be solved with VISA locks. Basically, in your critical loop, you lock the session at the beginning and then do an unlock. In your non-critical loop, you have a VISA Lock Async that waits for the resource to be available. There's a shipping example called Locking.vi.

[Will.D]

Wow...  that was so terribly simple I should kick myself!  (not to degrade your solution in any way though, I appreciate it!!)

Thanks

[Will.D]

Yeah, sorry 'bout that.  I've actually never used a DAQ (at least with LabVIEW), so I didn't think about the confusion my wording might have caused.

I'll look into using VISA, and the VISA Lock though.  I've never actually used it, I've always ever only used the GPIB read and write, and made my own subvi's to communicate with instruments.

Thanks for the suggestion.

[tbob]

I didn't know VISA locks existed, but that is probably the best way to go.  Learn something new every day.  Thanx Dennis, or should I call you "da xia"...

[Dennis_Knutson]

I haven't done much with the locks either. I'm running a TestStand sequence that tests 10 UUTs in parallel and every two cards share a common instrument so I've had to learn a thing or two.