Convert a normal number to binary?

[Dennis_Knutson]

Sorry, I made the change to the case statement before I noticed you had the incorrect value. It should be 3F.

You only need two cases. One for 3F and another one set to default. This can just have the value 0. You would only need other cases if you wanted to do something unique in each case.

[Graziano]

I'm trying to help to make your question to become the longest discussion on LV forums! Congratulation Vr6Fidelity!

[Vr6Fidelity]

Ok then I made some changes, I used the semi-rube setup.

I changed everything to 3F and I had the ID wrong and changed that.  

[RavensFan]

---

VR6Fidelity wrote:

Now if I Send 63, the request values command it goes like this.

1. I send the 63 command

2. it says ack

3. It sends me data

4. I reply ACK to let it know I got the data.

---

It still looks like you are missing step #4 in your case structure in your version 10.

You had also said it took a long time to run (I assume when the other errors were causing problems).  That is caused by your 10 sec. timeout in the initial serial port setup VI.

Message Edited by Ravens Fan on 08-02-2007 10:46 AM

[altenbach]

---

@Vr6Fidelity wrote:

... I used the semi-rube setup.

---

Or you could just branch off the "type" enum and make the cases the same as in the first case structure. 🙂

This will make the code easier to read because everything depends on the same primary value. RIght now, the second case depends on the first case in a complex way that might be hard to understand in a few months. [If type=timeout -> value =xxx --> if value=xxx, do yyy] vs. [ if type=timeout -> value=xxx AND also do yyy later.]

From your program logic, there shouldn't be any bytes at the port unless we had a timeout case condition. You could just check if the number of bytes at the ports is zero or not for the second case structure.

[Vr6Fidelity]

Raven you are right!

as a matter of fact I fixed this before you even respond. Also there is a bit ofa timing issue so i threw a wait in there or else i loose part of the message. This works great now. I get ALL acks back and just the 28 proper bytes of data.

Now all i need to do is figure out how to send it the speed signal, and then break up the data and interpret it!

[Vr6Fidelity]

Ok thanks to Dennis, Altenbach, and Raven the vi works Great.

I just need to add 2 more functions.

1. I need to add a button to the array of buttons, and have a special case for that specific button when it is pressed. I need this because that button will be "Change speed reference". The change speed command (x10) requires a longer 8 byte sent message because it will have a 2 byte number in the [Data] section. No other transmitted commands that i will be using have anything in the [Data] section.

2. After that the last thing I need to do is to work with the 28 bit "response" from the controller. That is text right? How do Break that down into little pieces? most of the answer i will be discarding, but i would like to pick out the current, voltage, and actual speed variables.   

[Dennis_Knutson]

You can see reply 30 for an earlier discussion on how to handle the speed. Here's a modified version of you last VI that just adds another case statement. For the returned data, you can use the String to Byte Array function. Once you have an array of bytes, you can use the index array function to get the bytes you are interested in.

[Vr6Fidelity]

So I spun the motor! Woo hoo!

However, whatever you type in for speed, the motor spins at 32,000 regardless of the value you type in?

I did some probing: i type in 20,000 and the first 1 byte is "7" and the second byte is "208"

These do not seem to be HEX values.

[Dennis_Knutson]

You are constanly forgetting that the default probe is set to display decimal. A decimal value of 208 is hex D0. You've got the string indicator at the input of the VISA Write that you can look at. What does that say? You can also create a custom probe with a numeric indicator set to display hex.