Communication with Lab View

louieho

I am trying to use a Stamp2p to relay I2C data from a system to a PC running labview and subsequently have labview giving the Stamp the frequency information to set the output of a PALPWM chip.

The problem I am facing is dropped communication between the Stamp and the PC. When I use labview to send a message. The Stamp for some reason does not always get it. I have to throw the send routine into a while loop to try a couple of times before the stamp can read it once. Once the stamp read the data, it then send back a sting token to acknowledge receiving the message. Unfortunately, the string sent does not always get received on the Labview end even though the comm port on the pc has a buffer. Is there anyway to setup labview, the stamp to ensure data is not lost? Debug terminal on the Basic Stamp editor does not seem to drop data like Labview does, how can I make my communication more robust.

Thanks.

Louie

Kevin Wood

Could you post your code?

Chris Savage

Something to keep in mind is that the BASIC Stamp does not have a FIFO Buffer or UART so if it’s not at the SERIN command when the message is sent it will be missed. If you use the I/O pins with a line driver you could enable flow control and that would help your communication since the PC would not send the message if the BASIC Stamp wasn’t ready to receive it. I hope this helps. Take care.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

louieho

Chirs,
· How should I implement the line driver? Do you have an example on the extra electronics needed to implement the driver? From the manual, there is a part about hooking up and I/O pin to one of the DB9 pins. But the wording seems to suggest there is more to that than just setting up a wire connection.
· Do you have a schematics where I can refer to?
· Thank you.

Regards,
Louie

Unsoundcode

Hi Louie, I have something in mind that requires a hardwire flow control so I will be looking at the reply to your last question with interest

I know nothing about Labview but using Visual Studio I have used a method of software flow control where the Stamp tells the application it is ready and waiting to receive data.

Because the PC has a buffer the ready signal sits there until the PC application gets around to reading it and then sends on the data.

The Stamp set up is something like this

TX,"Rdy"

RX,timeout,Data_in

the timeout gives your PC app time to process and doesn't hang your Stamp program if the data is not sent.

If its set up right the response is very reliable and fast

Jeff T.

Chris Savage

The MAX232 chip is a 5V Line Driver that generates RS-232 signals using on-board charge pumps. The data sheet for this page shows the general schematic configuration. You need only connect the BASIC Stamp I/O pins to the TTL I/O on it and the RS-232 to the PC serial port. One side’s RX goes to the other side’s TX and visa-versa…Of course you have to define your handshaking lines on the BS2 as well. I hope this helps. Take care.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

Kevin Wood

You might be able to get away with adding some manual timing pauses in both the PBasci & LabView code. What's probably happening now is that the BS@ & LabView are both going through their read / write cycles while the other device isn't ready.

louieho

I did position the programs so that the Stamp is doing SERIN forever waitng for the LabView to deliver the message. The unfortunate thing is that the msg delivered by Labview never get received on the first trial. Often, it takes like 10 tries before the Stamp can pickup the message. I know because I have my labview program to be running in a loop. It will send out the message, pause for 100ms and then read from its com port buffer to see if the Stamp sent a response. It will then display the loop counter and repeat the loop. The loop counter often goes up to 17 and 18 counts.

I think hardwiring for handshake will be a good idea. I just don't know how.

Also, because I am hacking into a system and bypassing its controller, I can only see changes by measuring the signals from teh PALPWM chip. As you can see from my code, I have added some lines that cause the changing of frequency to allow myself to see which point of the code have the stamp run pass. This is how I get to "see" if the stamp is waiting for instruction or have already got the instructions and proceeding from there.

Louie

Kevin Wood

It's kind of difficult to understand the process flow of your program. You might want to pare down your Main subroutine to a loop something like this:

DO
GOSUB GetInput
GOSUB DoSomething
LOOP

where GetInput handles the input from LabView and DoSomething calls the appropriate routines based on the result of GetInput.

I think you can do this without hw flow control, but you might have to start with a simple send / receive program that does only that. As you start adding other processes / functions for the BS2 to complete, you'll need to adjust the r/w timings between the 2 in order to compensate for the additional timing overhead of the subroutine calls.

louieho

I have written simple test comm program. And used Labview to send out a single number. Since there is no time out, the stamp waits for the msg from PC. If I have Labview to open a serial port at com1 and then send out a single number and then close the com port, the Stamp will not do anything. Only when I loop the write to comm port command in lapview will the stamp get the msg.

So in terms of timing. I know the Stamp is already waiting for the input. It is just for some reason, when the PC sends the msg, Stamp my not necessary get it.

'

---

[noparse][[/noparse] I/O Definitions ]

---

' {$PBASIC 2.5}
' {$STAMP BS2p}
' {$PORT COM1}

PpPin PIN 0 ' PWMPAL Serial I/O
OUTPUT 10
PpBaud CON 240 ' BASICSTAMP 2P CONSTANT VALUE FOR 9600BAUD RATE
TimeUnit CON 40 ' PWMPAL UNIT FOR 1ms
LOW 10
msg VAR Byte
SERIN 16, PpBaud, [noparse][[/noparse]DEC1 msg]
PAUSE 1
SEROUT 16, PpBaud, [noparse][[/noparse]"!"]
HIGH 10
END

Kevin Wood

Does this work at all?

' {$PBASIC 2.5}
' {$STAMP BS2p}
' {$PORT COM1}

PpBaud CON 240 ' BASICSTAMP 2P CONSTANT VALUE FOR 9600BAUD RATE

msg VAR Byte
SERIN 16, PpBaud, [noparse][[/noparse]msg]
DEBUG msg, CR
END

louieho

I'll give that a try. Are you suspicious that [noparse][[/noparse]DEC msg] causes the problem?

By the way, I found a program Portmon.exe and were able to see the traffic on the serial port. I'll be studying how the Stamp and the Lbaview program interacts. My initial try seems to indicate that the PC throws out the msg everytime. It's not something in my labview code that makes me think that it sent the msg but in actual fact never physically sent it. All the msg went out fine. However, I see plenty other activity on the port. So far the only one I recognized is opening/initializing the port. But there are other signals before and after I sent my message.

The interesting thing is that if I have the BasicStamp Editor running a debug window, I also see plenty traffic even when I am not doing anything. Seems like the debug window is actively talking/handshaking to the stamp. My labview communication only talk when it has msg.

Louie

Kevin Wood

It's possible that [noparse][[/noparse]DEC msg] is causing a problem. When you use DEC, you need to send a space to let the Stamp know where the number ends. So if you send "1", The Stamp will keep looking for digits until it receives a " " character.

If the Portmon.exe is the Microsoft(Sysinternals) version, that was my next recommendation. If you need more help with the info that Portmon is showing, the Sysinternals forums are a good place to start. As for the handshaking, if there is any going on it's probably initiated by Windows, not the Stamp, unless, of course you programmed the Stamp to do so.