USB to RS422/485 with com retention useful?

[Jon Arnett]

Hello all, we're in the midst of developing a new product, similar to others out there, but trying to make it better and more useful for real world users like yourselves.

The product is essentially a USB to RS422/485 converter with a 6 ft. cable built onto it which is resonably unique, but not completely original. Based on the chipset we've chosen, we have the ability to add a few other features to the product, including:

1) Com port retention, so unplugging and reconnecting the cable to a given laptop or PC will always be remembered as whatever port you confirgured it for

2) Com port renaming, so the cables can be named and rather than show up only as com ports, can show as the device name in the device manager

3) Traffic logging, so some debugging from collisions, etc. can be logged (obviously memory for logging is limited to a short interval, but still feasible) for later troubleshooting

Are there any other features for a product like this that you would find useful? If so, let me know, as we're in the final stages on development, but still have some time to make driver and software changes.

Thanks,

-Jon Arnett

Senior Product Manager, StarTech.com

[pete_dunham]

This sounds simple, but the COM retention sounds useful.

I have used similar hubs, with no retention, and have run into some weird pains:

For instance, after moving a test setup and plugging the hub back in, maybe into a different USB port, all of my COM ports in MAX get incremented from my last setup. MAJOR PAIN.

For instance...have a 4 port usb to serial hub with:

COM2, COM3, COM4, COM5.

After a move XP wants to reinstall drivers and now I have COM6, COM7, COM8, COM9.

Depending on how you have your resources coded, this can be at least mildly annoying.

[Jon Arnett]

This sounds simple, but the COM retention sounds useful.

I have used similar hubs, with no retention, and have run into some weird pains:

For instance, after moving a test setup and plugging the hub back in, maybe into a different USB port, all of my COM ports in MAX get incremented from my last setup. MAJOR PAIN.

For instance...have a 4 port usb to serial hub with:

COM2, COM3, COM4, COM5.

After a move XP wants to reinstall drivers and now I have COM6, COM7, COM8, COM9.

Depending on how you have your resources coded, this can be at least mildly annoying.

Thanks for the comments Pete; our release candidate currently avoids that exact headache. Was there any other annoying things you would like to see this product solve, or have we gotten lucky and nailed it as is?

[ShaunR]

Thanks for the comments Pete; our release candidate currently avoids that exact headache. Was there any other annoying things you would like to see this product solve, or have we gotten lucky and nailed it as is?

Will it support 4-wire? Most industrial applications use 4-wire full duplex. I think you wouldn't have much of a problem supporting 4-wire 1/2 duplex, but it'd be interesting to see how you tackle full duplex through a USB.

[vugie]

I would gladly see a diode indicating whether termination is proper. I dont't know if it is possible (however I think that EVERYTHING is either possible or expensive), but each time I deal with 485 I have problems with termination.

And 5 V output at the end of 6 ft cable is ALWAYS useful...

Edited September 2, 2009 by vugie

[Rolf Kalbermatter]

I would agree with the previous two post. Full Duplex support is important for industrial applications but with a little onchip buffer this should be doable.

Also the termination debugging is a good feature. Are there internal termination resistors and are they possible to be disabled?

What about bias resistors? The 5V power output on the port would be nice. Doesn't have to be high power, just a few mA in order to add some bias resistors to the setup on the other side.

Rolf Kalbermatter

[ShaunR]

I would agree with the previous two post. Full Duplex support is important for industrial applications but with a little onchip buffer this should be doable.

Don't think this would work. Electrons get confused when they meet each other on the other side of the pavement.

[Rolf Kalbermatter]

Don't think this would work. Electrons get confused when they meet each other on the other side of the pavement.

I'm probably missing the point in this. What do electrons on the pavement have to do with a proper bidirectional USB protocol?

Rolf Kalbermatter

[ShaunR]

I'm probably missing the point in this. What do electrons on the pavement have to do with a proper bidirectional USB protocol?

Rolf Kalbermatter

LOL.

Bi-directional isn't the same as full duplex. In RS485, you cannot have 2 devices driving the line at the same time, i.e in contention. (In full duplex you can TX and RX simultaneously since you have 2 pairs of wires). If 2 drivers try to drive at the same time (e.g a master is transmitting whilst the slave isresponding) the electrons get confused and you will get rubbish on the bus.

[Rolf Kalbermatter]

LOL.

Bi-directional isn't the same as full duplex. In RS485, you cannot have 2 devices driving the line at the same time, i.e in contention. (In full duplex you can TX and RX simultaneously since you have 2 pairs of wires). If 2 drivers try to drive at the same time (e.g a master is transmitting whilst the slave is responding) the electrons get confused and you will get rubbish on the bus.

Well, for that you have 4-wire on the RS-485 side, and while real bidirectional transfer over the USB bus is obviously not possible, the USB bus should, with the right driver, be fast enough to give to the system the impression that it is indeed bidirectional. I haven't used bidirectional communication where the timing was so critical that quasi-bidirectional operation would have caused trouble. IMHO such a system could never work unless all involved parties are 100% real 4 wire devices and their firmware is exactly the same. But that would be highly useless, unless you want to create a protected, private, proprietary communication network.

Rolf Kalbermatter

[ShaunR]

Well, for that you have 4-wire on the RS-485 side, and while real bidirectional transfer over the USB bus is obviously not possible, the USB bus should, with the right driver, be fast enough to give to the system the impression that it is indeed bidirectional. I haven't used bidirectional communication where the timing was so critical that quasi-bidirectional operation would have caused trouble. IMHO such a system could never work unless all involved parties are 100% real 4 wire devices and their firmware is exactly the same. But that would be highly useless, unless you want to create a protected, private, proprietary communication network.

Rolf Kalbermatter

I think you are still confusing Bi-directional with Full Duplex.

Take for example the Micro-Epsilon Micrometers and 2D/3D Profilers (just an example, since I used them recently). They can operate by "streaming" data back to the Master (important for high speed acquisition). If this were to be used in a half-duplex manner, then once switched into this mode, you would not be able to control the device since the device is continuously transmitting. However, with full duplex you can.

In another scenario, we have 1MBPs full duplex RS485 digital IO boards. The protocol is a command-response type which is appropriate for half-duplex operation since the devices don't start to transmit until a full message has been received. However, since we have upto 10 of these on a bus, most of the time, the RX line is saturated with messages. We can decide to ignore RX messages if they are a bit stale (since the devices must use hold-off and wait untill the line becomes free due to another device transmitting). But we cannot allow the device not to operate on commands immediately via the TX line.

Devices such as these are quite common. And "True" full duplex devices actually start constructing the response on the RX line before the entire TX message has been received.

[Rolf Kalbermatter]

Yes I meant for sure Full Duplex and the USB Bus is able to do that. So if you have an USB to RS-485 interface with 4 wire output (I think it is an oxymoron since RS-485 usually implies 4 wire connection), then there should be no problem in having real Full Duplex operation. The converter will need a little intelligence and buffer to store packets as they are transmitted over the USB bus back and forth, but for the normal observer it will look like real Full Duplex.

Bi directional as you seem to define it here makes of course little sense in such a setup.

Rolf Kalbermatter

[ShaunR]

Yes I meant for sure Full Duplex and the USB Bus is able to do that. So if you have an USB to RS-485 interface with 4 wire output (I think it is an oxymoron since RS-485 usually implies 4 wire connection), then there should be no problem in having real Full Duplex operation. The converter will need a little intelligence and buffer to store packets as they are transmitted over the USB bus back and forth, but for the normal observer it will look like real Full Duplex.

Bi directional as you seem to define it here makes of course little sense in such a setup.

Rolf Kalbermatter

Well. The difference may at first glance seem semantics. But it is fundamentally important. Whilst "Bi-directional" literally means "2-way", Full duplex means "2-ways simultaneously"!.

If you think of the difference between a walkie talkie and a telephone. One you cannot hear the person at the same time as you are speaking, the other you can. But they are both bi-directional.

Its much harder having an arguement on a walkie talkie than a phone...lol.

I wouldn't agree that RS485 implies 4 wires. (RS422 yes but not RS485). Almost all modern industrial PC's come with at least 1 COM port that is configurable to RS232, RS422 and RS485. Only when configured to RS422 does it use 4 wires. RS485 they use only 2.

The good thing is though, that RS485 works with RS422 but not the other way round So if you set the PC to RS422 you get true full duplex operation and can talk to RS485 devices. The penalty is that the bus cannot support as many devices.

I think we will have to wait for USB 3.0 for true full duplex USB

[Jon Arnett]

Thanks for the comments thus far, I'll answer what I can for now.

First off, the current prototype does not support full duplex over RS422, for the very reasons described above, that this hasn't worked out well in testing various devices as it's not "true" full duplex.

Regarding the power for RS485, this is something we may be able to add before launch. While most 485 don't seem to have this, I could see how the 5V there would be nice. From my research, people seem to like pin 8 for the 5V, and retaining pin 5 for ground, does this sound accurate to you folks?

[ShaunR]

TRegarding the power for RS485, this is something we may be able to add before launch. While most 485 don't seem to have this, I could see how the 5V there would be nice. From my research, people seem to like pin 8 for the 5V, and retaining pin 5 for ground, does this sound accurate to you folks?

You need to be careful here. The ground is a "signal ground" to differential voltage devices and may or may not be isolated (depending on the devices). The USB 5v supply is probably chassis ground. I'm not an expert on USB so it would be worth running it by your hardware gurus whether you need a separate "supply" ground to compliment the 5v. It may be important, it may not.