FactoryTalktotheHand
Member
I tried searching but either there aren't any answers out there for my Google-fu isn't up to snuff.
My customer has a laptop with Labview set up to transmit and receive ASCII strings from a 1769-L24ER Equipped with a 1769-ASCII module. We had some difficulty getting the ASCII module to receive strings from the laptop. I went back today and tried starting at the basics and building from there. We got the talking working both ways, except the Receiving on the ASCII module seemed a bit buggy. I hooked up his Labview laptop to my laptop with a null modem cable, and everything looked kosher. I'd receive his string followed by a Carriage Return, and Line feed.
But when it was hooked up to the module. He would send, and I'd receive the text but there would be a null character in front of it sometimes. Other times he'd run the routine 4 times before the ASCII module registered a receive, and it would be 4 of the strings with Null Characters and the ENQ character instead of Carriage Returns.
We tried a terminal program on his laptop and noticed that the first transmission would have a seemingly random number of leading null characters followed by the actual string, but after that it would work fine. After some more investigating we found that this was related to the opening of the port. For some reason, when the port is first opened, the first transmission will have those leading nulls, but every transmission afterwards will be fine.
Then, we looked at his Labview program, and he had set it up to open the port, transmit, then close the port. When we disabled the closing of the port and just left it open, the first string would have leading nulls, but the second and all subsequent would be fine, just like with his terminal program. He's currently reworking his Labview program to keep the port open, but I'm wondering why the ASCII module is behaving this way when the PC on the other side opens the port. When I hook his laptop to mine, and his labview program transmitts to my serial port, my terminal does not show all those leading null characters. It works just fine.
My customer has a laptop with Labview set up to transmit and receive ASCII strings from a 1769-L24ER Equipped with a 1769-ASCII module. We had some difficulty getting the ASCII module to receive strings from the laptop. I went back today and tried starting at the basics and building from there. We got the talking working both ways, except the Receiving on the ASCII module seemed a bit buggy. I hooked up his Labview laptop to my laptop with a null modem cable, and everything looked kosher. I'd receive his string followed by a Carriage Return, and Line feed.
But when it was hooked up to the module. He would send, and I'd receive the text but there would be a null character in front of it sometimes. Other times he'd run the routine 4 times before the ASCII module registered a receive, and it would be 4 of the strings with Null Characters and the ENQ character instead of Carriage Returns.
We tried a terminal program on his laptop and noticed that the first transmission would have a seemingly random number of leading null characters followed by the actual string, but after that it would work fine. After some more investigating we found that this was related to the opening of the port. For some reason, when the port is first opened, the first transmission will have those leading nulls, but every transmission afterwards will be fine.
Then, we looked at his Labview program, and he had set it up to open the port, transmit, then close the port. When we disabled the closing of the port and just left it open, the first string would have leading nulls, but the second and all subsequent would be fine, just like with his terminal program. He's currently reworking his Labview program to keep the port open, but I'm wondering why the ASCII module is behaving this way when the PC on the other side opens the port. When I hook his laptop to mine, and his labview program transmitts to my serial port, my terminal does not show all those leading null characters. It works just fine.
