06-30-2010 11:48 AM - edited 06-30-2010 11:49 AM
Flatten To String is your friend. Say it with me. Think of donuts rolling around in your mouth. Mmmmmmm.... gurrrrrggle... Flatten To String...
The Flatten To String will convert a number to a raw "hex" string (i.e., a string in which the bytes are raw values, not ASCII codes).
Now, as far as your VI.... oh boy... yeah, you've got a lot of problems:
I would also suggest reading up on some design patterns, such as the producer-consumer and the state machine.
06-30-2010 11:57 AM
I can't see any reason why you could not write directly. There is no way the instrument would know that the data originates in a file or not. You are already writing to it directly. It is VISA that reads the file and then sends it to the device. The data written is exactly the same if you pass it to a normal VISA Write.
Yes, the run continuous button is bad. In addition to the other comments, I would suggest you look at using an event structure with a value change event for the controls.
06-30-2010 11:57 AM
Hi smercurio_fc,
Although the thought of donuts in my mouth was pleasant, flatten to string didn't unfortunately prove to be my friend. Just tried it and still I get not what I expected from my device.
As far as the clusters, you're right, I didn't know that, certainly when I resolve the problem I have now, I will look into it!
06-30-2010 12:03 PM - edited 06-30-2010 12:04 PM
@Skata wrote:
Hi smercurio_fc,
Although the thought of donuts in my mouth was pleasant, flatten to string didn't unfortunately prove to be my friend. Just tried it and still I get not what I expected from my device.
As far as the clusters, you're right, I didn't know that, certainly when I resolve the problem I have now, I will look into it!
Then there's something you're not telling us. If the device wants a value in the way you described it, that's what you should use. Keep in mind that you cannot must send complete bytes over the serial port. Thus, 12 bits needs to be sent as 2 bytes (16 bits).
06-30-2010 01:52 PM
Your string generation looks strange, to say the least.
0
0
Slider1
Slider2
Slider3
...
_0_
_0_ (times 1434)
07-01-2010 06:05 AM
Well, smercurio_fc indeed I hadn't understood things clearly. The device uses a quite strange way (to my eyes at least) of using the data.
If you could help me, I include the manual that they sent me. Important pages are 12, 13 and 16 I think.
TXWFM command asks the device to send to the computer the waveform it has stored in its ram.
RXWFM command sends from the computer the waveform to the device.
I also attach the file that I got with the TXWFM command, if that helps a bit more.
07-01-2010 11:56 AM
Anyhow, I found out what I need to do! Finally! Actually, I need to feed the data produced in the attached 1.vi to the also attached 2.vi, concatenate all these ASCII characters onto one file and send it to the device.
Remark: Now the code in the 1.vi looks waaaaay better!thank you for your recommendations!
Questions:
1)In the 1.vi, I just want all the numbers to appear one after the other, no spaces or CRs in between. How can I do that?The only characters I am having a problem with, are the cluster ones.
2) The resulting string that will be produced from 1.vi, will be fed to 2.vi (there where the 3000 now is) (of course in the end both will be implemented into one VI, I just separated them for easier showing them to you). How could I make it in such way that each number of the string from 1.vi goes through the process in 2.vi?
Again, thank you in advance!
07-01-2010 01:22 PM
@Skata wrote:1)In the 1.vi, I just want all the numbers to appear one after the other, no spaces or CRs in between. How can I do that?The only characters I am having a problem with, are the cluster ones.
The CR/LF is being inserted by the Array to Spreadsheet String function. The extra spaces are due to using " %d" rather than "%d". Your original code had the spaces. Since you don't want any spaces then instead of using Array to Spreadsheet String you can just use the string conversion functions to get an array and then use Concatenate String to flatten the array to a string. See attached modifaction of 1.vi. Note the use of Initialize Array rather than loops to create the arrays.
2) The resulting string that will be produced from 1.vi, will be fed to 2.vi (there where the 3000 now is) (of course in the end both will be implemented into one VI, I just separated them for easier showing them to you). How could I make it in such way that each number of the string from 1.vi goes through the process in 2.vi?
Based on the information that you previously uploaded, I don't think that's what you want to do. At the very least you need a header, which is what's shown in the text file. Also, you don't need to create the big long string if the end goal is just the data as raw bytes. I skimmed over the documentation and I think I understand what's going on, but I won't be able to look at this until late this afternoon. Got work to take of.
07-01-2010 01:38 PM
Again, smercurio, thank you for your reply.
I attach where I have got to so far. Notice that I have used return commands to separate the value of each sample, so that I can pick it up easier and convert it to ASCII code.
First of all, the header when you send the file is not needed. The header is only transmitted from the device when you request the waveform from it. Second, since you cannot update the value of just one sample (and the use of the TWEAK command isn't the best choice), isn't it compulsory to send the whole big string?
Again, thank you very much for helping me with my problem!
07-01-2010 10:22 PM
Sorry about not getting back to you sooner, but I had a busy afternoon. Based on what I read, it seems to me, that what I had shown you before using the Flatten To String should work. You should start off with numbers rather than strings. In other words, where you're creating arrays of the digit 0, you really need to be using the number 0. The ASCII digit 0 is not the same as the number 0. The unit wants to see 1500 samples, of 2 bytes each. If a sample is zero it wants to see 00 00 (2 bytes, with each byte being 0). Thus, you should do something like the attached example to create the string to send to the device.
Second, since you cannot update the value of just one sample (and the use of the TWEAK command isn't the best choice), isn't it compulsory to send the whole big string?
I haven't read the whole manual, and I'm not familiar with the instrument, so I don't know why the TWEAK command isn't the best choice. If that's the only other way to set the values of samples, and you believe it's not a good way, then yes, you'd need to send the whole 3000 bytes.