When reading continuous serial information to Putty, Docklight or Hyperterminal, the information is unrecognizable on my laptop. If tested on other laptops, the information is legible and accurate. Is there possibly a blanket setting that I could have incorrect for receiving that information?.
Related
Im trying to develop a ble application, where a peripheral device (a Ti CC2650LP) reads sensor data via UART and writes them to a characteristic. The central device (a Win 10 PC) reads this characteristic via notification and outputs it in a special software.
My problem is: when I use my test pc everything works fine, but when ich use a different pc with my software i always get the same readings. It seems i cant access the characteristic. Everytime i reconnect the peripheral as a bluetooth device, the reading changes, but the software still only shows this one reading. I can see in my software, that the characteristic gets read but the value doesnt change. I'm pretty sure its a connection issue.
Has anyone had this kind of issue before?
I am controlling a device over serial connection using LabVIEW (version 7.0). It is connected using USB, and is installed as a virtual serial port on the computer (running Windows XP). Every now and then my device crashes when my program sends a command, and it is unable to accept any more input (the device itself also stops working) until it has timed out.
I've looked at the serial port traffic using Portmon. Whenever the device crashes the serial driver sends the command I send using my program four times instead of just once, with an IOCTL_SERIAL_GET_COMMSTATUS command in between. I cannot see what this last command returns, but I assume something happens in the communication earlier on. I'm thinking my configuration of the port is not entirely right, but I have no idea how or why. I open and close the connection to my device every time I want to write something to it.
For completeness' sake: it has a baud rate of 9600, 8 bits, no parity, 1 stop bit, and no flow control. I'm aware that the correct settings of these parameters depend on the device, but the manufacturer has not supplied any recommended settings.
The driver is a DLL of some sort? If so, this is the most likely source of your problem, and you likely will need to contact the author of the driver. LabVIEW does have crashing bugs, but by far the most common source of crashes in simple communications apps is a buggy third-party DLL.
In other words, I doubt this is a LabVIEW problem at all and that you would have the same difficulty if you wrote a C program to talk to this driver. I only know what you've posted here about your system, but after many years of chasing down such issues, I would start with the device manufacturer/driver author.
If you have evidence to the contrary, please share.
I have been programming this little WiFly RS232 device PuTTY. It is a small grey device that pretty much just sends data from an RS232 port wirelessly to our web server. There is a giant advanced user manual I have scanned through many many times now looking for someway to fix this and you can find it here: http://ww1.microchip.com/downloads/en/DeviceDoc/50002230A.pdf
This device is already hooked up to the web and the web server and I have posted data from other devices with it before. The issue I am having with it now is that the data that I am getting from the scale is in a really weird format. Originally it would send very weird looking character, then using "set opt format 0x7" I was able to get it to send the data in hex.
I can't seem to figure out how to translate that data to decimal so we can view the weight values correctly on the website. There must be a command for this that I am just missing or maybe it is more difficult than I realize.
I work in the weighing industry and spend a lot of time talking to various scales via RS232.
Most scales on the market send the weight data in Ascii format with a [cr][lf] terminator, e.g. "NET 2.045 kg[cr][lf]". If you are getting strange characters back, it is usually down to a mismatch in baud rate etc between the scale and the client. The scale manufacturer will usually have a communication manual which will detail the com protocol and give you an idea of what you should be receiving.
Have you tried communicating with the scale via HyperTerminal or YAT etc?
I hope this helps.
I had a PC connected to a PLC (Mitsubishi Q Series) via a USB2RS232 cable. The cable was plugged into the PC side, which was then plugged into a Serial cable and then into the PLC. I hade the baud rate set to 19200 and everything worked fine.
My problem was that every now and then the PC would blue screen on me. When I checked through the dump files the problem seemed to be related to the driver for the USB2RS232 cable (ftdi). I update to the latest driver but still bluescreening (Pc was running Windows 7).
Anyway I replaced the PC with another which had a dedicated RS232 port. Now I keep getting communication issues which is indicated by the response by the PLC. Just by chance I lowered the baud rate down to 9600 on both the PC and PLC. The issue seems to have gone away.
My question is why would removing the USB2RS232 cable cause me to have to slow down the communication? Both devices can communicate at speeds greater than 19200 and I would have thought going from serial port (PC) to serial port (PLC) with a serial cable would be better.
EDIT: Problem maybe solved - still testing
Thanks to some of the input from you guys, I may have solved the problem. Here are the following points I went by to get the speed back up to 19200 when using straight RS232 to RS232.
Even though no noise was detected on the equipment, a shielded cable was used.
The PC program would wait 100ms between sending data to the PLC. I read somewehere that 100ms is a good approx for PLC scan time.
RS232 Communication between modern PLCs and modern computers is often a hassle. These are some things I look at what it's not working:
The cable. Lots of cables are nonstandard, and have nonstandard internal jumpers and whatnot that can increase error rates and lower throughput. It is possible that your USB converter is more advanced and is autodetecting something with your cable and compensating for it.
The OS on the PC. Windows versions newer than Windows 98 don't seem to have the best support for serial communications.
Interference. Be especially careful of drives near the comm line. If you are using unshielded cables, a drive that runs intermittently can cause exactly the problem you describe, where you get an intermittent failure, but no noise at all whe the equipment is idle and you go check.
From your description I would guess that you have your equipment in a "noisy" environment - judging from the previous blue screens and now the issues with a regular RS232.
Have you tried to run the setup elsewhere with same hardware but other environment?
See if you can get a better isolated serial cable and/or use an EMF-meter to measure electric/magnetic fields around your setup.
Also worth to check out would be to put in another RS232 card in the PC to see if you have issues there, it could be that you had bad luck and the RS232 has broken.
Edit
Are you sure the speed is higher than 9600 with the USB converter? maybe it has negotiated down the speed? (disclaimer: not sure what brand you are using and how intelligent it is).
I wrote a program using tcpip sockets to send commands to a device and receive the data from the device. The data size would be around 200kB to 600KB. The computer is directly connected to the device using a 100MB network. I found that the sending packets always arrive at the computer at 100MB/s speed (I have debugging information on the unit and I also verified this using some network monitoring software), but the receiving time differs a lot from 40ms to 250ms, even if the size is the same (I have a receiving buffer about 700K and the receiving window of 8092 bytes and changing the window size does not change anything). The phenomena differs also on different computers, but on the same computer the problem is very stable. For example, receiving 300k bytes on computer a would be 40ms, but it may cost 200ms on another computer.
I have disabled firewall, antivirus, all other network protocol except the TCP/IP. Any experts on this can give me some hints?
I've found the answer to this question. The problem is due to the even/odd number of packets before the last fragment packet caused by the Nagle's algorithm.
see the link which is very informative:
http://www.stuartcheshire.org/papers/NagleDelayedAck/