Convert a normal number to binary?

[altenbach]

---

@Vr6Fidelity wrote:
THE VI DOES NOT WORK!

---

Some more details would be helpful here. This statement is too generic! 🙂

1. Does it have a broken arrow?
2. Does it produce incorrect strings?
3. Does it fail to communicate with the instrument?
4. Is the checksum wrong?
5. Do some aspects work correctly?

As mentioned, I removed all the VISA stuff, so to communicate with your instrument you would need to put all this back in.

[Vr6Fidelity]

I run the Vi on the computer connected to the machine and nothing happens. Vi seems to work fine.

Seperate unrelated question:

It seems that when requesting various information, or sending information of different types my message is going to vary in length.

For instance I do not always have the DATA aspect of my bitstream, how do i Get the build array to work with warying levels of inputs, as all the inputs need to be filled?

[altenbach]

---

@Vr6Fidelity wrote:
I eliminated a button, and re-coded what the hex codes were so they did what they said.

---

Whatever you attached has the same number of buttons as before and the same diagram constant for the responses. I don't see a difference.

[BillMe]

Does anyone else think "LabVIEW training" would be a good suggestion here?

[Vr6Fidelity]

You paying for it? my company certainly isn't. Im me and ill send you my adress where you can send the check.  

[Vr6Fidelity]

Ok i have figure out why It didnt write before. I have fixed that, but it still dosent seem to work.

Dennis? Input?

[RavensFan]

I think you may need to look at your architecture.  You are using a local variable to write out your string to the VISA.  It may get old data, because the event structure times out after 250 ms thus allowing the loop to iterate again.  If the loop iterates, the i node value increases, but if there is no action, it never gets recalculated for that first byte block counter (which in my opinion is a very awkward way of handling that communication, but it is what it is).

Every 250 ms, or faster if a button gets clicked, you go 0, 1, 2, 3.  But if it times out on some iterations, such as 1 and 2.  It will write message 0, message 0 again, message 0 again, message 3.  Either the timeout should be set to -1, or put the VISA write functions into the event structure as well.  Or you should probably do both.

Message Edited by Ravens Fan on 08-01-2007 11:36 AM

[Dennis_Knutson]

Why did you place the VISA Write outside the event structure? It does not belong there. You are doing a VISA write before the string is built. You need to understand the basic dataflow principle of LabVIEW. Put the write inside the same event where the string is created. DO NOT use a local variable. The VISA Configure Serial Port and the VISA Close should be outside the while loop.

http://www.ni.com/academic/lv_training/how_learn_lv.htm

[RavensFan]

Let me correct my earlier statement.  I do now see you have a timeout case that does execute and send something every iteration.  So the problem really is the dataflow which Dennis had more clearly stated in his e-mail

[altenbach]

---

@Vr6Fidelity wrote:
... but it still dosent seem to work.

---

Again, you need to be much more specific than that! What do you do, what do you get, what to you expect to get instead, etc...

Here are a few things that stick out right away looking at the current code:

The serial configuration belongs before the loop because it needs to be done only once. The "visa close" belongs after the loop. IT makes not sense to configure a visa session, write, read, and close it every 250ms, over and over again.

There is no reason to have a local variable. You actually create a race condition because the local variable will be read before it receives updated data from the event structure. You must wire from the "write to visa" indicator directly to the "visa write". (You can even eliminate the "write to visa" indicator. It is only useful for debugging at this point).

Your checksum calculation is still completely off. Right now, you calculate the checksum of some diagram constant instead of the actual data. As mentioned before, you also no longer include the size value in the checksum calculation for some reason.

One annoying feature is that you constantly maximize the front panel and diagram. Why? This make debugging more difficult because you cannot watch both at the same time. Basically, we operate under severe tunnel vision.

I assume you only want to read from the serial port in the timeout condition unless it sends some kind of acknowlendgment after each command received.

For testing, you should slow things down by increasing the timeout. If a value only shows for 250ms, you might not be able to read it.