Programming a BK precision 8500 in List Mode?

[Carlos_Ing]

Hello, communicating the burden BK PRECISION 8500, is done by sending packages of 26 bytes each. Communication always starts with the same byte (AA), known as byte start. When I remote communication with the load, setting tension (the tension increases through a while) and read data for home value of tension. When the load responds to an instruction not always starts with byte AA. The first byte can be 66 5F AA ... bringing the reading of the values of instruction 5F is incorecta. If any of those who works with the burden has some VI that works perfectly when successive send commands, if kind enough to notify the forum. Thank you.

[Daklu]

I'm putting together a simple driver for the BKP 8500 right now and have not seen the issue you are referring to.  Can you post the code that is causing the trouble?

[Carlos_Ing]

The input voltage less than 22V. I could send her to see VI as the communication?

[Sputnikrent]

Hi Carlos,

Can you please explain your code a bit more, and what the different VIs do? It is difficult for me to follow your code because there are no comments, and I do not have the BK Precision 8500 to test with.

Let me know, thanks!

[Daklu]

Sput, I've added some comments and debug code to Carlos' code.  It's really ugly now but serves the purpose...

-------------------------------

Carlos, I believe I figured out what the problem is.  I'll try to explain it as best as I can; be sure to ask questions if I'm not being clear.

When a 'Read Inputs' command (x5F) is sent to the device, the entire 26 bytes is not always read, leaving the remaining bytes in the serial port buffer.  On the next read command the serial port reports more than 26 bytes.  The first bytes out are those left over from the previous read command.  That is why they do not always start with xAA.  If you run the LV85xx vi I modified and have the 'Bytes at port.vi" front panel open you can see it happening.

Here is the sequence that is supposed to happen:

1. Send command to device (x5F)
2. # of bytes on port = 26
3. 26 bytes read from port

This is what I'm seeing when the error occurs:

1. Send command to device (x5F)
2. # of bytes on port = 26
3. 4 bytes read from port   [22 bytes remain in the port buffer]
4. Send command to device (x2C)
5. # of bytes on port = 48  [22 from the previous command + 26 from this command]
6. 48 bytes read from port  [the previous bytes are sent before the current bytes]

I have no idea why all the bytes in the port buffer are not being read.  My solution, which I'll be implementing in my driver library, is to check and make sure all 26 bytes are read from the serial port before leaving that vi.

[Daklu]

Carlos,

Here's a beta version of the BK 8500 driver I've been building.  It works for the most part--there are a few vi's that haven't been implemented yet and the documentation isn't finished.  Find and run 'Rapid Reading Inputs.vi'.  It's very similar to what you had put together.

If anyone wants to take this driver and expand on it you're more than welcome to it.  I don't have the expertise to make it good enough for the Instrument Driver Network.  Any comments on better ways to put the driver together are appreciated as well.

Message Edited by Daklu on 05-01-2008 11:30 PM

[Carlos_Ing]

Hi Daklu, thank you very much for your reply.

One solution was that it had taken him to read the data in port until they are zero, by instruction, that entry into the loop until all the data are read, and finally rebuild the investigation with all the data read. But this into the system to be very slow, because the loop sometimes took time to finish run. As he did not know whether the problem was a bad programming came from BKP (8500) so my question in the forum.

[Billy James]

I have a quick request / question for anyone reading here.  I noticed that there is a .zip file within this thread that contains vis for a number of commands used to work with the BK 8500 load.  Unfortunately, I am working with Labview 7.1 and when I unpack these, they request v8.5.  I was wondering if anyone could be so kind as to take screenshots of these vis and email them to me as gifs or jpegs so that I may try and recreate them in 7.1.  I am really stuck on a project right now  trying to work with this BK 8500 load, and would be most appreciative for the assistance.  Thanks ever so kindly.

James

browndogsstudio@yahoo.com

[mbuel]

I know I'm digging up a zombie thread here, but unfortunately I'm trying to get this beast working in a project as well. The approach I take when doing this is to write a state machine to control it completely as a virtual instrument, then pass in what I need either as a cluster or class.

I've got everything working, (after modifying the B&K drivers, they are a mess) except for the configure transient portion. This does appear to be a driver level problem as when I run their example code I'm getting the same error. I've attached a picture of their code (which is a mess, I haven't don much here besides connecting the byte count from the write in to the read, which fixed a read bug with their driving not counting the correct byte count then skipping the read altogether. Someone earlier was complaining about the same problem) along with the error message from their error handler and it's output after reading the output from the read. 

This happens even when I run the example code, so I do think there is something else wrong here, just asking for some more eyes on it if you happen to be working with one of these beasts with the transient functionality.

If anyone is interested I can also upload the changes I made to the driver along with my VI to control the machine.

Thanks in advance,

Morris

[mbuel]

I fixed my code by moving the function set after the voltage and timing set. When the function is set before the voltage and value, it does not operate correctly and throws the previously attached error message.

I'm still not sure why the BK example code was throwing the same error as the VI blocks are arranged in this linear pattern. Set A and B, then set the selected Function.