I have a Symbol/Motorola LS4278 barcode scanner. I've downloaded the Symbol OPOS Driver software from Symbol's support website. I'm trying to Claim the device using the VBDemo.exe app that comes with the Symbol OPOS Driver software. However I am getting the error code OPOS_E_NOHARDWARE. This means that the device is "not connected or is powered off". Yet, the device is indeed connected and working fine. If I scan something with it into Notepad.exe, then the scanned data appears in notepad. Please advise urgently what I am missing.
"If I scan something with it into Notepad.exe, then the scanned data appears in notepad."
This tells me that your scanner is programmed for "Keyboard Emulation" mode, sometimes called HID mode. In the user manual, there will be a programming barcode that you can scan to put it into the proper mode. Typically for Symbol scanners, it is called "IBM USB mode". Once you scan this programming barcode, you should be able to use the scanner with OPOS.
Related
Bought thunderboard, card in its box says go to: www.silabs.com/start-thunderboard
but I get good old: "Error 404 -- Not Found"
So I ran Simplicity Studio 4 with the Tboard plugged in to my laptop.
But SS4 doesn't detect the Tboard.
I'm trying to get example 'C' code for doing BLE -- specifically, for Gatt reads and writes
You can find the out of the box documentation here. For more useful info on using Thunderboard, see the links below:-
Bluetooth workshop: Develop on a BG22 thunderboard kit
Getting started with Silicon Labs BG22 chipset
Thunderboard BG22 West Side Electronics
Regarding the board detection, check that you can see a COMPORT in the Device Manager. If not, I would try it on a different PC and if it still isn't detect then I would contact support here.
I'm working on a project that involves connecting a single-board computer (either a BeagleBone Black, or a BeagleBoard X15) to a Mac via USB OTG, and then delivering basic mouse/touch input (pointer coordinates and left/right-click events).
This process should be technically very similar to connecting a mouse (or, more accurately, a touchscreen-style device that receives precise mouse coordinates) and passing some ordinary HID input to MacOS. So I don't need most of the complexity of IOKit - I don't think I need to create a kernel extension; I should just be able to create an instance of a HID for which MacOS already has generic kernel extensions.
So I'm delving into IOKit to figure out how to create the device instance and provide input. However, nearly everything I'm reading about IOKit involves creating and registering new kernel extensions, services, etc. - none of which is germane to my project.
So far, the only relevant leads I've got are the I/O Registry Explorer and the contents of /System/Library/Extensions. Several items in there look promising, such as AppleDHIDMouse.kext. However, I cannot find any examples of code to bridge the gap: how my USB-connected device can connect with the kernel extension, create an instance for itself, and send commands.
Any help? Thanks in advance.
Either your device is fully USB HID compliant, in which case you shouldn't need any code at all on the Mac side, or you'll need to create a kernel extension.
How far have you got? What does your device look like in ioreg/IORegistryExplorer? (The latter is from the "Additional Tools for Xcode", downloadable from https://developer.apple.com/download/more/ )
Does your USB device's interface report as HID? (bInterfaceClass 3) The device itself normally reports as a composite device (bDeviceType 0). bInterfaceProtocol and bInterfacSubClass also have defined meanings in the context of HID, and should probably both be 0 for a "tablet" style device. With that in place, macOS should pick up your device as a HID device and try to drive it with one of its built in HID device drivers.
The way HID devices work is through "reports" - event data structures with a flexible format/layout, which is defined via the device's "report descriptor". What buttons, input axes, etc. your device has is defined there.
For an example of a USB "tablet" device (absolute coordinate pointing device) that works with macOS, check out the code for the USB Tablet device that Qemu emulates. That might be a good starting point for the report descriptor of your own device.
If your device doesn't conform to general USB HID conventions and uses some custom protocol, you'll need a custom kext (up to macOS 10.14) or dext (from macOS 10.15 onwards) which will most likely implement a IOHIDDevice subclass. An example of such a driver is the open source Mac driver for the Xbox 360's game controller, which doesn't behave like a standard USB HID device.
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 a number of Windows 2000 systems that we are trying to use to program the new Arduino Uno and Mega devices. These boards now come with a USB connection, an upgrade from the prior FTDI. I'm not able to download the Arduino code into the board from a Windows 2000 system
The supplied drivers are *.inf files that modify the standard USB driver that comes with Windows (in this case Windows 2000).
I go through the process of setting the port, setting the device and doing the download. The download fails, and the apparent error is that the PC can not communicate with the board. I've checked the port, adjusted the baud rates, etc. I've even moved the port number from a high port number (ie COM12) to a lower port (COM2) without any success. I do see activity on the rec/xmt lights on the Arduino board, so some type of data is being sent and received.
I'm looking for:
Someone who has been able to download files from Windows 2000 to the Arduino
or
A way to shim inside the USB driver to be able to watch the traffic going up and down to the board so I can continue to debug this.
or
Some general tips for things to look at in the .inf file that need to be set/not set to make it work on Windows 2000.
I know the boards work I've used them on a different set of Windows XP systems. So I know to some extent the install is good and that most of what I have works.
Full dumps can be found on the Arduino forum, http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1291090110/.
This is the information produced by the AVRDude program while it's trying to download the code.
this could be a long shot, but I jsut recentlz had problems uploading too. Fist of all, how long is the USB cabele you are uploading from? Mine in one case was too long and th arduino woul lose sync. Secondly, and this might just be a silly oversight (like i did) do you have things wired in the digital pin 0 and 1? These are used for the communication, and if there is anything else plugged in to them the upload will also fail.
As I said, long shot but those were two errors I had.
I have an Arduino-based device which connects through USB.
I'd like to detect it from my Qt 4 application, using QExtSerialPort (or whatever necessary), when it's plugged in.
If this weren't possible, I thought I could somehow get a list of the system's port names and just try all of them in search for my Arduino (where I'd implement some kind of handshaking procedure for it to detect it correctly). My concern in this approach is that I'm not sure if a device (for example, printer) would get damaged if I send some kind of handshaking ack at a different baud rate.
So, I don't really know where to start for any of them. Which would be the best approach? How would I implement it?
I believe you can find list of serial ports on Windows by looking into
HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM
registry key
Each serial port on a UNIX system has one or more device files (files in the /dev directory) associated with it:
System Port 1 Port 2
IRIX® /dev/ttyf1 /dev/ttyf2
HP-UX /dev/tty1p0 /dev/tty2p0
Solaris®/SunOS® /dev/ttya /dev/ttyb
Linux® /dev/ttyS0 /dev/ttyS1
Digital UNIX® /dev/tty01 /dev/tty02
more details on serial programing on POSIX systems here
Since your device is USB, your UART port will be emulated by some kind of conversor in his hardware. So first you must understand what driver is being used on your system.
The most common SERIAL->USB conversor uses PL2303/PL2301 chip, so it would create a path on /dev, if its the first device, it will appear as "/dev/ttyUSB0", but you may also see the list reading the proc path (like "cat /proc/bus/usb/devices").
Under Windows it usually creates a virtual "COM", just go to device manager and check the port.
When you are sure about how the HW talks to your system, you may use QExtSerialPort for wrapping the system API and talk to the device.
Way too hard and too platform specific, using weird Windows Registry keys or rely on hard wired device nodes on Linux.
You are on the right way. Get QextSerialPort or QSerialDevice (which I preffer in my projects, because it got integrated in Qt5), have a look at the examples and simply use it. In both libraries you get some kind of port enumerator class which returns you a list of all configures serial ports. Only platform/device specific settings you will have to do manually (like getting RS485 in half-duplex mode on my current embedded project), but "standard" problems are perfectly encapsulated in a QIODevice implementation.
You can use both QextSerialPort and QSerialDevice like a file. Open it (instead of a filename you specify the device name ie. "COM1" on Windows or "/dev/tty0" on Linux, depending on your configuration) and then read or write like you are doing it with an ordinary QFile, QBuffer, Qwhatever-inherits-from-QIODevice.
If you have any problems opening the port and communicating, don't hesitate to ask! :)