Convert a normal number to binary?

[Vr6Fidelity]

Ok dennis your VI does communicate with the controller. Thank you.

I will continue to add onto it and screw everything up.  😞

I need to sort out what the buttons do.

When you press reset you get 01 instead of 00 etc.

Then I need to figure out how to deal with the ACK and NAC response.

The vi sends a command, and it works, but after 2-3 seconds the drive has a fault. I think it is because I am not acknowledging is response or vice versa. The infamous ack or nak.

Then i need to figure out how to parse out its massive data response.

[RavensFan]

In your default case where you search for true in the array, don't increment that index with the +1 before feeding it to the index array.  It winds up returning the code for the value below the button that you pressed.

[altenbach]

---

@Ravens Fan wrote:
In your default case where you search for true in the array, don't increment that index with the +1 before feeding it to the index array.  It winds up returning the code for the value below the button that you pressed.

---

That is as designed! if we don't find a match, the search returns a -1 which also needs to be handled. Ading a +1 gives function values starting with zero. Element zero is for "not found", one is for the old "0", etc.

If you don't add "one", you need another case structure to handle the "-1" case. All that's needed is a lookup table with the right values in the right place taking care of the increment. 🙂

[Vr6Fidelity]

A cookie for raven's fan. Works great now.

NEW question:

The communication protocol is VERY "chatty" and It requires an "ACK" (Hex 06) for every damn thing sent or recieved. So you press the controller on button, and the controller responds 06 a zillion times before at trips out in 2.5 seconds. So I need to

1. Send a message

2. Recieve its 1 byte ACK or NAK response (ACK=yes=06 NAK=no=15)

3. And then I need to send it an ACK to let it know I get its transmission.

So, I see the property node "bytes at port" I'm thinking i need to somehow use one of those bytes at port property nodes. sense when there is 1 byte at the port, and then immeadiatly send off an ACK (06).

What would be the best way to do that?  

[Vr6Fidelity]

OK so i have talked to the controller guy again. and identified another minor problem.

The BLOCK COUNTER, which runs off the iteration terminal does not count in HEX. once it rolls thru 9 it goes to o not A

Not only does this cause an odd block counter value, but It invalidates the math on the checksum calculation.

how do i get the iteration counter to convert to hex?

[Dennis_Knutson]

The iteration terminal gets converted to a U8 which counts from 0 to 255. That is the same thing as counting from 0 to FF. There is nothing that needs to be done. You are confused about the format and precision of a display. I thought this topic had already been discussed in this thread. With a control/indicator, changing the display format does not change the number.

[RavensFan]

---

@Vr6Fidelity wrote:

OK so i have talked to the controller guy again. and identified another minor problem.

The BLOCK COUNTER, which runs off the iteration terminal does not count in HEX. once it rolls thru 9 it goes to o not A

Not only does this cause an odd block counter value, but It invalidates the math on the checksum calculation.

how do i get the iteration counter to convert to hex?

---

I don't think you have an issue here.  Later in the code, there is a byte array to string which does the conversion to hex for you.  Let your code run and you will see that the second byte goes from 09 to 0A.

You should also look at Altenbach's comment in Reply 60 about how you are calculating the checksum.  Your latest code still shows the checksum being calculated for a constant array.

As for your ACK vs. NAK., if all you expect is a 1-byte response, fine.  If not, look at the results of the read and see if they match what you're expecting.  If so, do another write in line that sends an ACK (hex character 06).   If not, write out a NAK (hex 15 (decimal 21)).

[Vr6Fidelity]

I do not understand what Altenbach meant in response 60 about why the Checksum is incorrectly calculated. The checksum is the reason the VI is cuurently not working.

Please try to explain it to me as you would a complete idot ( such is my labview knowledge )

[RavensFan]

Your checksum algorithm was calculating the checksum on array constant of {0 0 0 0 0 0 6} rather than on the actual data you were sending out.  That data would vary depending on which button you pressed.  Look at the attachment to see the modification that I think you would.  I can't guarantee this will work exactly as I don't know exactly what the algorithm is.  For instance, I don't know if the byte for array size as to be calculated in as well.

By the way,where is speed divided by 10 supposed to go to?

I also simplified the build array to do everything in one.

Message Edited by Ravens Fan on 08-01-2007 05:04 PM

[Dennis_Knutson]

Actually, the check sum has to be calculated with the byte count. The correct code was in response 28.

Message Edited by Dennis Knutson on 08-01-2007 03:05 PM

Message Edited by Dennis Knutson on 08-01-2007 03:05 PM