04-23-2010 12:09 PM
Dear all,
i need help figuring out some parts of my actual project...
The system is composed as follows:
At a remote location there's a PC with 2 RS232 ports (COM1 and COM2) that are now used to capture two serial streams from different machines (baudrate 9600, 8 databits, 1 stop, no flow, non parity). This continuous data flow is just plain ascii text with no termination char (if i connect a printer to those ports i get text strings).
This PC has an assigned IP.
I've already built a hyperterminal-like application that shows in two differents text indicator the data-flow and that logs on the pc (.txt file) the collected data. It has a friendly interface and includes some other features that i require.
The hard part comes now:
I'd like to forward both data streams over LAN to a remote PC. This PC (static IP address) must just show the 2 separate streams as it's being captured by the remote PC.
Any idea?
Up to now i managed to obtain nothing. I've also modified samples like sample_data_client/server.vi or other similar VIs to suit those to my requirements... nothing.
I simply can't forwar to this remote location the serial data.
Thanks in advance.
04-23-2010 01:53 PM
Post what you have attempted so we can see what is going wrong.
If you started with the TCP/IP examples that LabVIEW provides in the example finder, there should be no reason you can't get them to work for your application.
04-23-2010 03:32 PM
Just connect the Output of VISA Read to the Input of TCP Write, but only if conected over TCP/IP and only on the server side.
Or you can use two parallel while loops:
one for VISA and one for TCP/IP Server.
On the client side you have to open connection to the server and connect TCP Read to a String Indicator.
04-24-2010 06:11 AM - edited 04-24-2010 06:17 AM
Here it comes.
This is just an extract i've created to test the feature that points at localhost.
As i start writing in the server 'data in' field, the same char should appear in the 'data out' field on the client vi.
Server should not need any enter key (or similar) to transmit the string to the client.
Regs
04-24-2010 06:12 AM - edited 04-24-2010 06:19 AM
04-24-2010 10:45 AM - edited 04-24-2010 10:48 AM
04-25-2010 04:11 AM
I added a control box in order to modify the 'bytes to read':
if I select 0 it doesn't read anything.
1: shows just the last character I've typed by deleteng always the char read before the last one.
x to 99999: nothing usefull.
I think I shoud left te value '1' selected and create a sort of buffer that keeps on reading the received data in order to keep track of it. Any idea?
Note that the txt data could reach the size od 0.6MB/month.
Thanks in advance.
04-25-2010 04:21 AM
I created a vi in order to test this feature only (the other parts of the project can be distracting).
If you want to run it too and give it a try... there's a .dll version in this discussion that contains both the client and the server VIs.
It's harder than it seems.... I'm still not getting any luck!
04-25-2010 10:06 AM
_Fabio_ wrote:I added a control box in order to modify the 'bytes to read':
if I select 0 it doesn't read anything.
1: shows just the last character I've typed by deleteng always the char read before the last one.
x to 99999: nothing usefull.
I think I shoud left te value '1' selected and create a sort of buffer that keeps on reading the received data in order to keep track of it. Any idea?
Note that the txt data could reach the size od 0.6MB/month.
Thanks in advance.
Of course 0 doesn't read anything. You are telling it to read zero bytes.
1 doesn't show just the last byte. It shows all the bytes but reads them so fast you can only see the last byte.
The problem is that right now, your two VI's don't really do anything. One takes what you type and sends it to the other. The other reads it and just displays it on the screen and then the data is lost forever. Your not saving the data or doing anything with it. You haven't really put in anything there to accomplish the real part of your goal of reading the serial port on one end, and logging the data to a text file on the other end.
You really should go back and look at the server and client examples again. You've stripped off most of what they are doing. Right now you have no idea how many bytes to read. If you read 1 at a time, you know you'll get them all as they come in, but it is really inefficient. If you do read x to 99999, you might miss bytes or it will wind up timing out if you try to read x bytes, but only x-1 bytes or less were sent.
The key part of the examples is that the sender first sends a know number of bytes that tell how many bytes follow, then it sends that number of bytes. The reader first reads those 4 bytes, then uses that to determine how many more bytes to read. You get more data through efficiently, and the reader doesn't waste time waiting for bytes that may never come because it knows how many bytes to expect.