Help needed with RS232-bluetooth

[bogiasac]

Goodmorning to everyone.

I have simplified the code as you suggested but i am still getting crashes.
I am using a simple DAQmx example to acquire data every 5 sec and writing that to a global.
I then read the data convert it to binary, send the length of the string first and then the whole string.

I think the problem is on the transmitting side.

I am sending a string of data (in my case two waveforms) to the 'serial write' every 5 sec. The problem (i think) is that the first set of data is being continously written to the 'serial write' vi, until the second lot arrives(there is a 5 sec delay), thus the buffer gets full on the receiving side (i think, i dont know if it is possible to check this). The unflaten from string on the receiving side cant handle this amount of data and crashes.

The solution to my problem might thus be a routine that that only sends the first string of data once and then waits for the second string of data before it sends something.

This is my understanding of my problem but please have a look at my code and give me some advice. I am slowly going mad with labview crashing all the time.

All the best
Alex

Here is my simplified code in LV8

[bogiasac]

In LV7.1 format

[tst]

I don't have any experience with working with a serial connection in this manner (normally it's reserved for speaking to devices, not computers), but it might be possible that the crash is coming from the VISA functions. I would try to set some debugging information (probes, breakpoints, etc.) to check this. Maybe the buffer isn't large enough for your data? When I use VISA I normally just use the configure VI and then immediately start reading and writing. I never bothered with any of the other VISA settings. 

I would also get rid of the global and either take the data directly from the acquisition into the flatten function or else I would create a queue and place the data into it. By setting the dequeue timeout to -1 you can make the communication loop only send data when there is data in the queue.

I would suggest that you simplify this even more - don't do conversions of the data. Just take the data you're getting from the acquisition and send it just as it is. Also, get rid of the loop inside the sending VI - it only helps to confuse. In any case, this method of data transfer wasn't designed for working over a serial connection, but if the connection is reliable I don't see any reason it shouldn't work. If it keeps crashing you should tell us when it's crashing and what error it throws. A screenshot might also be a good idea.

[bogiasac]

~Hi TSt and thanks for your reply.

I simplified the program even more as per your advice.

You will be glad to know that it seems to work.

I combined the the acquiring vi and the transmitting vi together and that seemed to make things work.

As i stated earlier i think the problem was that i was transmitting the same data at least 5 times before a new cycle of 'freshly' acquired data arrived for transmission.s

I did not remove any of the visa settings as in my opinion they are necessary. I alo left the flatten and unflatten vi in, as the serial write vi only accepts converted data anyway.

As to why it crashed, i can only guess. I am pretty certain though that it was the unflatten from string vi's faults (or my coding to be more specific). It was receiving to much data and it couldnt cope with that. to answer your question i was not getting any error message from labview . IT JUSTED CRASHED. Many, many, many times. I used the probe and before labview crashed, the unflatten from string vi gave a warning. I dont remeber exactly what it said but it was something like the Unflatten VI has detected that there were more data to process and then it would crash.

I agree with u that serial was not designed for data transfer but from my point of view it seems quite versatile to do the job. What i am doing is not very different from emulating a device sending data at a  given period of time.

I have one last question. You mentioned earlier that the visa configure can only be set to a positive integer (because it is a I32). Is there, however another way (except setting it to its largest allowable number) to make the serial communication run indefinately?

Thanks for your patient advice and wish you all the best for your future.

[tst]

---

@bogiasac wrote:

As to why it crashed, i can only guess. I am pretty certain though that it was the unflatten from string vi's faults (or my coding to be more specific). It was receiving to much data and it couldnt cope with that. to answer your question i was not getting any error message from labview . IT JUSTED CRASHED. Many, many, many times. I used the probe and before labview crashed, the unflatten from string vi gave a warning. I dont remeber exactly what it said but it was something like the Unflatten VI has detected that there were more data to process and then it would crash.

I agree with u that serial was not designed for data transfer but from my point of view it seems quite versatile to do the job. What i am doing is not very different from emulating a device sending data at a  given period of time.

---

In general, I agree with you. There shouldn't be any reason for this not to work. If you've run into one of the corner cases where LV crashes because of something you should use the investigate errors dialog which pops up after a crash to send the data to NI. Just to check, I send a string of several MBs into the unflatten function and it didn't crash, so if that is the source of the crash, there is more to it than just a large string.

---

I have one last question. You mentioned earlier that the visa configure can only be set to a positive integer (because it is a I32). Is there, however another way (except setting it to its largest allowable number) to make the serial communication run indefinately?

---

I don't work that much with serial communication, but you might want to try looking into VISA events. In any case, even if you can't do this, you can simply add another case structure which will do nothing if no data has arrived and the read function timed out. That way, your code will just iterate on an empty loop until there is data. The other option is to seperate the communication from the data processing by using a queue as I suggested earlier.