When I write software to control Zaber devices, I sometimes get strange behaviour that I don't understand. Usually it's caused by bugs in my script or other software, and sometimes it's a hardware problem like a loose connection on the serial port.
How can I see exactly what commands my software is sending and how the device is responding? I'd like a kind of log file that I can search through to see what's causing the errors.
Most often, I'm writing scripts in Zaber Console using C#, but I also write LabVIEW VIs using the Zaber instrument driver.
There are several techniques to see the raw data being sent to and received from Zaber devices. Some are restricted to certain operating systems, others only work with some software. Most of the options involve looking at the raw data, so look in the user manual for details about the message format, and a list of command numbers.
Below, I'll try to list a few options and tell you when they are available.
Zaber Console Log Window
Only in Zaber Console, only on Windows.
This is the easiest technique if you are using Zaber Console scripts or plug ins. The window in the top-right corner records all the requests and responses for you. You might find it easier to track down the problem if you clear the window just before the problem occurs, and stop the script right after. One shortcoming is that some corrupted messages are not shown, you just see a partial packet timeout error. If the messages you want are getting scrolled off the top, change the log size on the advanced tab.
Portmon
Only on 32-bit Windows.
Portmon was a great tool, and I'm sad that it never got upgraded to 64-bit Windows. If you're still running a 32-bit version of Windows, it's worth trying. I found that the latest version 3.03 didn't work for me, but 3.02 still does. If the official version doesn't work, then searching for "portmon 3.02" will usually find some site that carries the old version.
In version 3.02, open the Computer menu and choose Connect Local.
From the Capture menu, choose Ports: COM1, or whatever serial port you want to connect to. Make sure your software is currently closed, or Portmon won't be able to connect to the serial port. Sometimes after using Portmon, you have to restart the computer to make it release the serial port.
From the Edit menu, choose Filter/Highlight... and set the Include to be IRP_MJ_READ;IRP_MJ_WRITE
On the Options menu, enable Show Hex and Clock Time.
Try sending some commands from your software, and then look at the Portmon window. You should see something like this after you widen the Other column.
In the screenshot you can see two commands being sent (1 block of 6 bytes for each command), and two responses coming back (6 blocks of 1 byte for each response). Remember that the display is using hexadecimal numbers, so the first command is 14 hexadecimal or 20 decimal (move absolute).
HHD Serial Monitor
The best replacement I've found for Portmon is HHD Serial Monitor. It's not free, but it has a trial period, and the license is pretty cheap. I think it might be more powerful than Portmon, but it's not as easy to use.
Here are the settings I found to be useful for logging Zaber device commands. After installing and starting the Device Monitoring Studio, I clicked on the serial port I want to monitor in the list of ports. That opens a list of available views, and I double click on Request View. On the right-hand side, I click the Start button. That opens the request view, and I click on the Complete tab.
Now when I send some commands to the device, I see read and write requests with hexadecimal and text display of the data. Here's the equivalent of the Portmon screenshot above.
Again, the first command is 14 hexadecimal or 20 decimal (move absolute).
NI Spy or NI I/O Trace
Available with LabVIEW
This option isn't as easy to read, but it comes with LabVIEW, and you can read the documentation on how to start it. Here's a screenshot of the NI Spy tool. I think it came with older versions of LabVIEW.
Related
I'm getting this error...
The semaphore timeout period has expired.
On this line...
ThePorts.ActivePort1.Open();
...but I only get it from time to time. When it happens, it happens over and over again. Then the problem goes away, for hours or days, then it comes back.
The serial port is a USB with a BlueTooth connected.
I think this guy was having a very similar problem, but not in C#
Freeze on SerialPort.Open / DeviceIoControl / GetcommState with usbser.sys
As best I can estimate, I have read his entire problem, and the resulting comments, and the answer, but I really can't figure out which one fixed his problem, or if C# is significantly different from what he was experiencing.
Thanks for any help for the clueless. This is the actual code where it's happening.
public static void Open_ActivePortWeWillUse(String Drone_StringNameFromUser)
{
SerialPort TempSerialPort = new SerialPort(Drone_StringNameFromUser, (int) SerialPortSpeed);
ThePorts.ActivePort1 = TempSerialPort;
ThePorts.ActivePort1.DataBits = 8;
ThePorts.ActivePort1.Parity = Parity.None;
ThePorts.ActivePort1.StopBits = StopBits.One;
ThePorts.ActivePort1.DataReceived += new SerialDataReceivedEventHandler(OurBackGroundSerialPortReceiver);
ThePorts.ActivePort1.Open(); // "Sometimes" Error hits here
}
Okay, I am now connecting without the semaphore timeout problem.
If anyone reading ever encounters the same thing, I hope that this procedure works for you; but no promises; hey, it's windows.
In my case this was Windows 7
I got a little hint from This page on eHow; not sure if that might help anyone or not.
So anyway, this was the simple twenty three step procedure that worked for me
Click on start button
Choose Control Panel
From Control Panel, choose Device Manger
From Device Manager, choose Universal Serial Bus Controllers
From Universal Serial Bus Controllers, click the little sideways triangle
I cannot predict what you'll see on your computer, but on mine I get a long drop-down list
Begin the investigation to figure out which one of these members of this list is the culprit...
On each member of the drop-down list, right-click on the name
A list will open, choose Properties
Guesswork time: using the various tabs near the top of the resulting window which opens, make a guess if this is the USB adapter driver which is choking your stuff with semaphore timeouts
Once you have made the proper guess, then close the USB Root Hub Properties window (but leave the Device Manager window open).
Physically disonnect anything and everything from that USB hub.
Unplug it.
Return your mouse pointer to that USB Root Hub in the list which you identified earlier.
Right click again
Choose Uninstall
Let Windows do its thing
Wait a little while
Power Down the whole computer if you have the time; some say this is required. I think I got away without it.
Plug the USB hub back into a USB connector on the PC
If the list in the device manager blinks and does a few flash-bulbs, it's okay.
Plug the BlueTooth connector back into the USB hub
Let windows do its thing some more
Within two minutes, I had a working COM port again, no semaphore timeouts.
Hope it works for anyone else who may be having a similar problem.
This error could also appear if you are having network latency or internet or local network problems. Bridged connections that have a failing counterpart may be the culprit as well.
I had this problem as well on two different Windows computers when communicating with a Arduino Leonardo. The reliable solution was:
Find the COM port in device manager and open the device properties.
Open the "Port Settings" tab, and click the advanced button.
There, uncheck the box "Use FIFO buffers (required 16550 compatible UART), and press OK.
Unfortunately, I don't know what this feature does, or how it affects this issue. After several PC restarts and a dozen device connection cycles, this is the only thing that reliably fixed the issue.
Too many big files all in one go. Windows barfs. Essentially the copying took too long because you asked too much of the computer and the file locking was locked too long and set a flag off, the flag is a semaphore error.
The computer stuffed itself and choked on it. I saw the RAM memory here get progressively filled with a Cache in RAM. Then when filled the subsystem ground to a halt with a semaphore error.
I have a workaround; copy or transfer fewer files not one humongous block. Break it down into sets of blocks and send across the files one at a time, maybe a few at a time, but not never the lot.
References:
https://appuals.com/how-to-fix-the-semaphore-timeout-period-has-expired-0x80070079/
https://www-01.ibm.com/support/docview.wss?uid=swg21094630
I had a similar problem which I solved by changing the Port Settings in the port driver (located in Ports in device manager) to fit the device I was using.
For me it was that wrong Bits per second value was set.
I was this problem with program RealTerm, then I entered into device manager and just disable the Bluetooth device connected into the port COM3.
The problem is with your cable not with your code or connection some cables are designed to send power only some are designed to send power and data we have to see those types of cables
I am trying to port a service written for Windows systems in C# onto Linux, with the aim of replacing Windows altogether. The hardware remains identical in both Windows and Linux environments.
So far this has gone great - I've installed Mono-complete, modified those bits that need modifying to stop it looking for Nuget, compiled the software with only cosmetic errors, run it with mono-service and have established communication with the Serial Port.
That's where things start going wrong.
I am able to open the port, and I am able to send a message to the port which results in the proper response.
By running 'cat /dev/ttyUSB0' I am seeing the proper response from the port - the symbol #
However the symbol is simply not being read by the software and I'm hitting a timeout every time.
I have changed nothing in the code except to open port '/dev/ttyUSB0' instead of 'COM1' (or whatever port it needs).
Why then can I write to, but not read from, the serial port?
I have tried messing with the Encoding of the returning bits, I thought it might be a big-endian / little endian issue but it is correctly sending the signal to the device ("M2" - no quotation marks).
Return communication also looks good - cat /dev/ttyUSB0 shows a series of '#' symbols being returned, each on a new line.
What is not happening though is the software then reading this, instead it is hitting the timeout waiting for the response.
I wondered if it might be a newline issue - but then why would it work as-is on the Windows system, and why would it send perfectly happily (newline currently is explicitly set to '\r\n')
Is there something specific to Linux that I am missing?
I know this is a while late, but I'd left the project to one side for a while and have only just picked it back up.
It turns out that the problem lies with mono not firing DataReceivedEvents, so when the code ported from Windows .Net came across listening for them they weren't being picked up because they weren't being fired.
I overcame this by spawning a new thread whose sole purpose was to listen on the port, and when serialPort.BytesToRead was greater than 0 run whatever code would have been run on the event firing.
I use as USB-SerialPort Converter for a Barcodereader. (Drivers for the converter are supplied on a CD -- company: digitus)
In my program (C#) I wait for SerialPortDataReceived-Events and proceed if I get values -- so far everything works fine.
The problem now is that I don't receive Data anymore sometimes.
The same readers and USB-RS232 converters as well as the same notebooks (lenovo, Win7) are used at 8 stations, but only at 2 of them I have this problem.
When I am in the situation that I do not receive Data when the reader read some, I can't see any problem. Windows says that the serial port is working fine.
But when I unplug the power supply of the reader and reconnect the COM-Port in my program it works again.
(And I do not think that the reader is the problem, because those readers are used a couple of hundred times in the company I work for)
So it must be the converter or the cooperation from the converter and the barcode reader!?
My next idea would be trying another converter, but is there any way to understand the cause?
Or did anybody have a similar problem?
Try disabling the "USB selective suspend" feature
Open Control Panel.
Click on Hardware and Sound.
Click on Power Options.
Click the Change plan settings link for the plan you're currently using. (If you change the settings on the power plan that isn't active, this won't work.)
Click the Change advanced power settings link.
Expand USB settings.
Expand USB selective suspend setting.
Select Disabled from the drop-down menu.
Click Apply.
Click OK.
If you're changing the settings on a laptop or tablet, you'll see two options: On Battery and Plugged in, so make sure to change those settings accordingly.
Once you complete these steps, Windows 10 will no longer power off USB devices connected to your computer, which can fix any problem you may have as a result of this feature.
While this guide focuses on Windows 10, USB selective suspend has been around for a long time, and you can use the same steps on machines running Windows 8.1 and Windows 7.
For more details check https://www.windowscentral.com/how-prevent-windows-10-turning-usb-devices#:~:text=When%20a%20USB%20device%20is,feature%20to%20fix%20the%20problem.&text=Windows%2010%20includes%20the%20USB,re%20not%20actively%20in%20use.
USB ports are terribly unreliable in this way. The only way to get a reliable serial.port is to use a PCI card or an Ethernet device server. You will never get a consistent connection through USB.
We get a bug reported in our serial port comms about one a month, and every single occurrence is due to someone using a USB to RS232 converter. As soon as we install better hardwarec the issue vanishes.
I'm getting this error...
The semaphore timeout period has expired.
On this line...
ThePorts.ActivePort1.Open();
...but I only get it from time to time. When it happens, it happens over and over again. Then the problem goes away, for hours or days, then it comes back.
The serial port is a USB with a BlueTooth connected.
I think this guy was having a very similar problem, but not in C#
Freeze on SerialPort.Open / DeviceIoControl / GetcommState with usbser.sys
As best I can estimate, I have read his entire problem, and the resulting comments, and the answer, but I really can't figure out which one fixed his problem, or if C# is significantly different from what he was experiencing.
Thanks for any help for the clueless. This is the actual code where it's happening.
public static void Open_ActivePortWeWillUse(String Drone_StringNameFromUser)
{
SerialPort TempSerialPort = new SerialPort(Drone_StringNameFromUser, (int) SerialPortSpeed);
ThePorts.ActivePort1 = TempSerialPort;
ThePorts.ActivePort1.DataBits = 8;
ThePorts.ActivePort1.Parity = Parity.None;
ThePorts.ActivePort1.StopBits = StopBits.One;
ThePorts.ActivePort1.DataReceived += new SerialDataReceivedEventHandler(OurBackGroundSerialPortReceiver);
ThePorts.ActivePort1.Open(); // "Sometimes" Error hits here
}
Okay, I am now connecting without the semaphore timeout problem.
If anyone reading ever encounters the same thing, I hope that this procedure works for you; but no promises; hey, it's windows.
In my case this was Windows 7
I got a little hint from This page on eHow; not sure if that might help anyone or not.
So anyway, this was the simple twenty three step procedure that worked for me
Click on start button
Choose Control Panel
From Control Panel, choose Device Manger
From Device Manager, choose Universal Serial Bus Controllers
From Universal Serial Bus Controllers, click the little sideways triangle
I cannot predict what you'll see on your computer, but on mine I get a long drop-down list
Begin the investigation to figure out which one of these members of this list is the culprit...
On each member of the drop-down list, right-click on the name
A list will open, choose Properties
Guesswork time: using the various tabs near the top of the resulting window which opens, make a guess if this is the USB adapter driver which is choking your stuff with semaphore timeouts
Once you have made the proper guess, then close the USB Root Hub Properties window (but leave the Device Manager window open).
Physically disonnect anything and everything from that USB hub.
Unplug it.
Return your mouse pointer to that USB Root Hub in the list which you identified earlier.
Right click again
Choose Uninstall
Let Windows do its thing
Wait a little while
Power Down the whole computer if you have the time; some say this is required. I think I got away without it.
Plug the USB hub back into a USB connector on the PC
If the list in the device manager blinks and does a few flash-bulbs, it's okay.
Plug the BlueTooth connector back into the USB hub
Let windows do its thing some more
Within two minutes, I had a working COM port again, no semaphore timeouts.
Hope it works for anyone else who may be having a similar problem.
This error could also appear if you are having network latency or internet or local network problems. Bridged connections that have a failing counterpart may be the culprit as well.
I had this problem as well on two different Windows computers when communicating with a Arduino Leonardo. The reliable solution was:
Find the COM port in device manager and open the device properties.
Open the "Port Settings" tab, and click the advanced button.
There, uncheck the box "Use FIFO buffers (required 16550 compatible UART), and press OK.
Unfortunately, I don't know what this feature does, or how it affects this issue. After several PC restarts and a dozen device connection cycles, this is the only thing that reliably fixed the issue.
Too many big files all in one go. Windows barfs. Essentially the copying took too long because you asked too much of the computer and the file locking was locked too long and set a flag off, the flag is a semaphore error.
The computer stuffed itself and choked on it. I saw the RAM memory here get progressively filled with a Cache in RAM. Then when filled the subsystem ground to a halt with a semaphore error.
I have a workaround; copy or transfer fewer files not one humongous block. Break it down into sets of blocks and send across the files one at a time, maybe a few at a time, but not never the lot.
References:
https://appuals.com/how-to-fix-the-semaphore-timeout-period-has-expired-0x80070079/
https://www-01.ibm.com/support/docview.wss?uid=swg21094630
I had a similar problem which I solved by changing the Port Settings in the port driver (located in Ports in device manager) to fit the device I was using.
For me it was that wrong Bits per second value was set.
I was this problem with program RealTerm, then I entered into device manager and just disable the Bluetooth device connected into the port COM3.
The problem is with your cable not with your code or connection some cables are designed to send power only some are designed to send power and data we have to see those types of cables
I am working on a personal project involving sending simple signals from my computer to a circuit via USB. Basically I am using the USB signal as the gate signal for a MOSFET which will in turn activate a relay to turn on/off various AC peripherals. For example if I want to turn on a light bulb for 5 seconds every minute I would be sending a 1 down the first wire for the first 5 seconds of every minute.
This is my problem: I have no idea how to manually send a 0/1 down a specific wire on a USB cable, or even interact with a USB port at all :(
So I guess there are multiple parts to this question, is it possible to interact directly with the bits being sent via a USB port? If so how would I do this? I am familiar with C++ and C#, so I really hope that you can do it in one of those...
Thanks!
edit Hmm so it looks like the USB port actually only has one 5V pin so direct USB interaction wont work. Going to take a look at a parallel adapter and get back on it.
USB is a bad fit for anything that doesn't have a USB interface at the other end of the wire. If you don't want to get into building your own USB device, I'd suggest buying a USB to serial adapter, which gives you two directly-controllable output lines (the flow control lines), or a USB to parallel adapter, which gives you more than 8 lines.
Chris Johnson's answer has a link to instructions for Windows serial port programming. You'll want to look at section 7 -- the SETDTR, CLRDTR, SETRTS, and CLRRTS are your flow control line toggles (for the DTR and RTS lines, respectively).
As far as hardware goes, a "1" (SET) value on a flow control line is +3 to +15 volts on the line, and a "0" is -3 to -15. Actual voltages can vary between devices; measure it to be sure. (EDITED; I got the 1 and 0 mixed up. The control lines use the opposite convention from the data lines.)
Here are Wikipedia pages for voltage characteristics and pinouts.
EDIT: Having done some more research on USB-to-parallel adapters, I don't think they will give the needed level of control. For best results, you'll need a PCI or PCMCIA parallel card, or a parallel port built into the motherboard.
I'm not a Windows programmer, but this library might be useful for controlling the parallel port's lines from Windows.
The easiest thing to do for this application is to use serial port emulation, either with a USB-Serial cable, or with a USB-Serial converter chip (e.g. the FTDI FT232) in your hardware device.
Either way, this allows you to interact with your USB device as you would a serial port (see, e.g. here for how to do this in C++ in Windows)
Much like Chris suggested, you can get a USB slave device from FTDI. $27 at digikey will get you a small board with all the fine wiring already done.
However, for your purposes the bit-banging mode described on page 39 of the datasheet would be much better than the UART mode (UARTs generate pulses at several kilohertz, you want to have the voltage stay at the level you set it to).
Hopefully your MOSFET will turn on with a 3V signal since the FTDI will put out approximately 3.1-3.2V for a high output.
Also, make sure you use the latest drivers from FTDI... a couple years ago they had drivers (WHQL-certified even) that caused frequent BSOD, and I've often found that driver CDs that come with hardware are several years out of date.
I built something very similar to what you are doing (I was running a car window motor from a usb device, used a mossfet H bridge (the HDR1X8 on the diagram) to drive the motor.). You need a USB to I/O device this is what I used (I got a U421, they fit perfectly over the center line of a breadboard, the 401 works well with breadboards too if you don't have a split one.
They give you a dll and you just link in to it with your code. its just as simple as making a call to WriteA and WriteB for writing out to your mosfet device. Be warned logic level lines are not meant to drive current so you will need to hook this up to a transistor if you expect any kind of medium to large current flow. See App1 in the application notes of the menu on the usbmicro site to see the proper way to hook it up.
Use a USB prototype board. It usually comes with a software SDK.
Check out these links from my web site:
1.You can use a usb to serial converter. All you need to know is here
2.You can use programming to access the usb directly but for this one you have to have a driver already installed for you device. Details are here