Help needed with RS232-bluetooth

[MarkLe]

Hi,

Problems relating to memory and LV crashing when using VISA generally mean you're trying to open too many references to a resource at any one time.

I would go to the Example finder in LabVIEW and have a look at the Basic Serial Write and Read example to get you started. It includes all the error checking needed to make sure you don't run into problems.

I would set up the VI on one end of your connection, and open Hyperterminal (included with Windows) or a similar program that monitors the serial port on the PC at the other end. Check that you can send strings from the VI to Hyperterminal to check the link is OK. If you get any problems, make sure that the port settings are the same at both ends, your cable is wired correctly and no other applications are trying to access the ports.

Once you're sure the link is working fine with your cable, then try it with the Bluetooth adapters and see how the link performs.

Hope this helps get you started.

Best wishes,

Mark

Applications Engineer

National Instruments

[bogiasac]

Hi MarkLe,

I have looked at all the serial and TCP examples within Labview. They all are extremely simplistic even for some one relatively new to labview like me.

I have addapted some code from a TCP example and i send the length of the strings first and then the string(as some 'veteran' suggested). Although this seems to work, i do from time to time get errors (like 'not enough memory to complete the operation', or that new data arrived before the data in the buffer had been read).

I have also addded a queue routine in hope that that would make certain that no information would be lost. However, it doesnt have any affect as the 'elements in queue' stays always at zero and i continue to get the errors mentioned above.

My question is:

1. Is there a way to send a string length of say 1024 every 100ms just to make sure that it has been recieved and read, before the next string of 1024 arrives???

2. Does anyone have some code on how to write an acknowledge routine so that the server waits for an ACK before it send more data, thus knowing that the client has received and read all the string length.

I have looked through the discusion room for hours and hours and i cant seem to find what i am looking for.

In my opinion you can not have trusted communication if your code does not contain a acknowledge routine. And since i am trying to send two waveform every 5s i think an ackowledge routine is vital so as not to lose any info.

Please if you have any suggestion or any code you are willing to share with me, dont hesitate to reply, or contact me at bogiasac@msn.com.


This is the code i have wrote so far.

[bogiasac]

Sorry forgot the VI's

[bogiasac]

In LV7.1 format

[tst]

Well, I had a quick look at it and I had some problems with insane objects and with the wiring (probably because of the change to the variant primitives), but I think I got the basic point.

One potential problem I'm seeing is that you're using Variant to Data to get the number of bytes instead of the type cast (which you're using for the display). I'm not sure whether this will definitely cause a problem (it seems to work for you), but in any case the duplicate conversion is unnecessary and I would stick to one method of conversion on both sides (the variant has error handling, so you might want to pick that).

The most likely reason for your queue being empty is that your dequeue loop has a much faster rate than your checking loop - when that loop runs it takes an element out of the queue and so it's unlikely that you'd run into a situation where the preview primitive runs when there are still elements in the queue.

The reason you're getting timeouts is that a serial timeout cannot be set to be -1 - it is a U32 value and can only be positive. As such it is coerced to 0 and unless you already have the data waiting in the buffer the function will time out. The solution to this would probably be to set a long timeout.

Another thing would be not to complicate the issue. You're passing your data through a queue and then through a local. This is bound to cause trouble, especially since the local is written to much faster than it is read from, which means you are sure to lose data. What you can do instead is either put everything in the communication loop (if you get data you immediately convert it to the waveform) or go with the queue approach and convert the data right from the queue.

However, since the queue method is mostly suited for situations like TCP or UDP communication where you can have multiple data sources, you're probably best off leaving everything inside the single loop.

The last thing I would suggest for now is to get rid of the "you typed" part. Send just the data you want to send. If you want to add other types of data you should create a protocol (let's say that the first byte of the message is a number representing the type of data you're transferring - when the client receives it it checks that byte and knows what to do with the data). You can check out the messaging protocol example I mentioned for a more complex version.

P.S. In general, your diagram is clean, but I would try to get it even cleaner. And try more documentation - it should help you more than anyone.

[bogiasac]

Hi tst,

I removed the queuing process as per your advice. I also replaced the type cast and changed the time out value of the serial config to something large.

After running the VI;s i dont seem to be getting any time out error, or buffer over runs.

However, i have now replaced my voltage and current generating VI's with a global variable that gets the data from an acqusition vi. Now Labview crashes every time i try and run the client vi.

I have removed the unflatten from string vi that seems to cause the problem. I am appending all the data to a shift register and from what i see, i continiously get the same data over and over again, though the transmitting waveform is changing continously.

I can see that the data that is written to the 'serial write' is changing, but the data on the receiver is always the same as the first transmission. What i mean here is that once the transmitter and receiver establish connection only say the first set of waveforms on the receiving side are what was actually transmited. I then just get a repetion of the same set of waveforms.

Do u have any bright ideas.

Please just spend 2 min of your time thinking. I have spend almost 1 month on what should be extremely simple.

Thanks in advance

Alex

[tst]

First, there is at least one mistake I made - the variant conversion would not help you in this case because you have to pass strings. You need to use either typecasing or flattening to a string.

Second, I don't see any reason LV should crash because of you using a global or an unflatten primitive. This is a relatively rare condition and could probably be solved by replacing bits of the code with other code.

Third, my best guess as to why you would be sending data X and receiving data Y is either because you're misunderstanding the way the program runs, you have the buffer full with old data, you are getting the data but not able to see that it's different (seems unlikely) or, since you're using a serial connection, you might have a termination character which you're receiving as part of your flattened string and which breaks the connection. I don't think that would be the case, because even so the rest of the data should remain in the buffer for you to see on your next read. I would suggest that you upload your revised code so we could take a look.

[rolfk]

---

@tst wrote:

Second, I don't see any reason LV should crash because of you using a global or an unflatten primitive. This is a relatively rare condition and could probably be solved by replacing bits of the code with other code.

---

Well, In LabVIEW 8 and probably 7.x the Unflatten function should have been improved to check for valid data that makes sense with the typedescriptor before attempting to do a conversion. In earlier versions Unflatten happely started to crunch on the data to sometimes run into an Assert if that data was not consistent. However this should cause at least an "out of memory error" or "An error has occurred in xxxxx.cpp, line yyy" dialog. Simply disappearing from the screen altogether is not something that should be possible in the Unflatten function.

Rolf Kalbermatter

[tst]

Well, Alex is using 8, which should even have (if I remember correctly) a standard error cluster for the unflatten primitive. In any case, it's not clear to me what this crash is and which part of the code is actually causing it, but I suspect it could be gotten rid of by simplifying the code.