I am building a CNC controller which has 1Gbps Ethernet interface for communction with a Desktop Windows. Right now I am using NPCap to implement a custom protocol to communicate between Windows and a CNC microcontroller for a high-performance link with low latency.
Problem: NPCAP is extremely slow. I benchmarked both the microcontroller firmware and NPCap. My microcontroller can easily go up to 700 Mbps in transmit and receive. But NPCap is giving me only 1 mbps transmit and 56 kbps receive. Is it that NPCAP itself is slow, or am I doing something wrong?
I see that Microsoft Winsock also allows some limited capabilities for RAW Ethernet. As of now, I haven't been able to get Winsock to work on my Windows application in SOCK_RAW mode. But before I go down the rabbit hole of using Winsock in RAW or give up and try to make my own network driver, I want to know if Winsock transfer speeds in SOCK_RAW are better than NPCap or are they similarly limited?
Related
So I'm trying to revive an old (late 90's) noise logger (Acoustic Research Labs EL-215 for those familiar) and I've been looking into USB-RS232 connectors. I have port settings from the original documentation which are as follows:
EIA RS-232-C
1200 - 19200 Baud
8 Data Bits
2 Stop Bits
Hardware Flow Control
(note: parity isn't specified)
I have an old Belkin F5U109 adapter, which hasn't worked so far - so I'm trying to work out how the Belkin is different to other USB-RS232 adapters. I also read that Prolific PL2303 and FTDI seem to be the leading USB-RS232 chipsets that nearly all modern USB-RS232 adapters seems to use.
What features should I look for in an adapter to give me the best chance of making it work with my hardware? Whats the main difference between the Prolific and FTDI chipsets?
I don't care which operating system I need to use as I'm proficient in Linux and can easily spin up a VM with VirtualBox or qemu if need be. Hardware uses DOS software, so could also run dosbox if required. Worst case I can reverse engineer the whole thing and write my own program to communicate with the EL-215, but I'd rather avoid that!
Any help much appreciated!
Edit: Here's what I've tried so far
That link seems to suggest that software flow control (XON/XOFF) doesn't work. I've investigated the device in trying to connect to and found that DTR and DSR are not connected, but RTS and CTS are. When I run the DOS software (through Windows XP on a VirtualBox VM, Belkin drivers installed, COM1 8,2, hardware flow control, no parity) which is supposed to connect with the device, I get connection error - it times out waiting for response from device.
I put the multimeter on the pins of the Belkin while using the DOS software. DTR goes from -9v to +3v momentarily, as does RTS. Obviously DTR is ignored by the device because its not connected, so RTS going high should trigger a CTS response from the device but it doesn't.
So I thought that the Belkin is perhaps waiting for DSR to go high before doing anything, so I bridged DTR to DSR, but still no response. I found it strange that DTR only momentarily goes high as if properly implemented it should stay high for the entire duration of the connection.
It's either the Belkin logic levels are not high enough (I think RS232 needs >3v to trigger) or it incorrectly implements hardware flow control. Belkin information about the adapter refers to connecting a PDA so maybe its a specific implementation for those devices...?
I have ordered FTDI and Prolific PL2303 adapters in the hopes that they might work better. Backup plan is to build a circuit to control RS232 pins individually with like an Arduino or something.
I have a raspberry pi 4 and a pc, I have to transfer files at very high speed than Ethernet and WIFI
if any possible methods are there Please tell me?
I'm not too sure if you're saying you want to transfer files over something other than wifi or Ethernet? If so, USB A to USB A should work for you. PCIe are downstream slots which you would be unable to connect to another system using that method. If you are able to plug up to each of the systems using ethernet, that's probably your easiest choice. As long as you bridge the connections and allow file printing and sharing, you should be able to see the system in your file explorer.
I was curious if anybody knows a way to connect two different computers together over a USB line and what API's exist to program this interface.
For Serial Ports its common to buy a "Null Modem" adapter to cross over the Transmit and Receive lines of the UART so that the computers can talk together. And then You would read and write them like normal windows files over special system files called "COM1", "COM2", etc.
I was wondering if there was an Adapter of some kind that could emulate this same behavior except for native USB protocol. I realize they have USB-to-UART adapters. That's not really what i'm interested in because the baud rate is very slow for uarts. I was looking for something with USB speeds to transfer from one computer to another that is not going over a network link such as ethernet or wifi.
This is what I have:
COMPUTER A<-->USB<-->UART<-->NULL_MODEM<-->UART<--->USB<-->COMPUTER B
Speed 110,000 Baud, whatever... to slow to transfer files... ok for text...
This is what I want:
COMPUTER A<-->USB<-->Crossover_Adapter<--->USB<-->COMPUTER B
Speed 480 megabits per second
Assuming this beast exists, how do you program it and where do you buy it?
The only solution that I know of is the "FTDI Chip USB-to-USB Null modem cable" that can transfer between computers two computers using USB ports at a rate of 3 MBaud (384 kbytes/s) That's a lot faster than using older serial ports with null modem cable that maxs out at say 115200 baud (14 kbytes/s). The FTDI chip cable can be programed in c/c++/c# just like a standard windows serial port by way of a virtual serial port.
http://shop.clickandbuild.com/cnb/shop/ftdichip?op=catalogue-products-null&prodCategoryID=92&title=Null+Modem+Cables
From Their Website:
USB NMC-2.5m
NMC In the era of legacy PCs with onboard RS232 COM Ports, it was
common practice to establish a simple communications network between
PCs using a cable popularly known as a Null-Modem cable. Typically,
such a cable would have DB9 female connectors on each end with the TX
/ RX and handshaking signals cross-connected so that the PCs could
communicate with each other via legacy COM ports.
On modern PCs the legacy COM Port connector is rapidly disappearing as
USB becomes the multi-function communication port of choice. However,
this presents a dilemma in application areas that previously relied on
legacy COM Ports for inter-PC communication.
A convenient solution to the problem is the FTDI USB NMC cable. From
the outside, this cable appears to be two USB type “A” sockets wired
together, however each of the USB sockets conceal a small PCB with a
FT232RQ based USB-UART converter IC plus support components inside.
The interconnect cable cross-connects the TXD / RXD data signals, RTS
/ CTS handshaking signals and interconnects the common GND reference
rail betwen the two converter PCBs.
When used together with FTDI’s supplied Virtual COM Port ( VCP )
drivers, the USB NMC cable may be used to establish inter-PC COM Port
based communication at baud rates of up to 3M baud. The standard USB
NMC cable p/n USB NMC-2.5m comes with an interconnect length of 2.5m (
8.2ft ) - other lengths may be available on request. Multiple operating systems are supported including Windows, Linux, Mac OS etc.
single cable
Another Alternative is to use Bluetooth which is also programmable just like a the older serial port.
I think I found the solution: Avnet Spartan-6 LX9 MicroBoard.
It has a USB on one end and an ethernet port on the other end.
http://www.xilinx.com/products/boards-and-kits/1-3i2dfk.html
I can put the fpga/microblaze-cpu in the middle to filter out traffic to make sure the link doesn't get hacked and maybe encrypted it as well.
Easy Computer Sync sells the null modem cable plus the data transfer software. The SW is versatile and easy to use. https://www.bravurasoftware.com/easy-computer-sync/ (I have no connection with other than being a satisfied user.)
I am developing a logic core to perform data transfer between a FPGA and a PC over ethernet, using a LAN8710 PHY on my FPGA board.
I've achieved to transfer some UDP data packets from the FPGA to the PC. It's a simple core that complies with the PHY transfer requirements. It builds the UDP package and transfer it to the PC.
To check the reception on the PC, I am using Wireshark and as said above, I receive the packets correctly. I've checked the reception with a simple UDP receiver written by myself.
But, I've noticed that I only receive these packets when Wireshark is running on the PC. I mean, if Wireshark is ON, my application receives the packets too, and the counter of received packets of the following picture increases. (This picture is not mine, just one from the internet)
http://i.stack.imgur.com/wsChT.gif
If I close Wireshark, the PC stops receiving packets and the counter of received packets stops. My application stops receiving too.
Although novice on networking topics, I suspect that this issue is related to PC-side. Seems like Wireshark is "opening/closing" the ethernet communication channel, or something like that. Does anyone knows about this issue?
To build a functional core to transfer data between a PC and the FPGA, I've developed a core to transfer and receive UDP packets. Next step will be ARP implementation (to let the PC identify my FPGA board, as I understand). What protocols are necessary to perform full-duplex data transfer between this 2 devices?
Thank you very much in advance,
migue.
Check whether you are able to get appropriate receive interrupt at ethernet driver level on PC-side for a single transmitted packet by FPGA. If you do not get the receive interrupt, check on the transmit side(FPGA) for appropriate transmit interrupts for packet that is being transmitted. This should mostly help you in cornering the issue.
As far as i know, wireshark is just a packet analyzer/sniffer. However, if wireshark is suspected, one option could be to try with alternate packet sniffer to rule out if any such scenario is happening.
A handy tool for determining problems in network and also for determining the network statistics shall be netstat. netstat -sp udp shall list down the statistics only for UDP. There are many other parameters that can be used with netstat for diagnosis.
After many months I solved it, I post to help someone stucked in the same point.
Finally I figured out that Wireshark uses a tool to access the network link layer of the computer. This tool allows Wireshark to sniff all incoming and outgoing packets at a specified network device. To do this, the first step is to OPEN the network device, and that's why my program only worked if Wireshark was open.
Regards.
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).