QUATECH ThinkQ QSE-100D-BA 4 Port RS-232 Serial Server (CHEAP!)

I had my Ocelot plugged in, but am not really using it right now. I can try to hook it up tonight, just need to install the driver.
 
Well, I'm going to get down in the bits tonight and see exactly what causes a write fail, since that's a CQC parameter, not an actual network event. It could be that maybe the driver isn't giving enough time for the write to complete, since I've already experienced issues with the datanab needing more time when using the quatech. There's clearly some latency issues when using the quatech.

Once I can positively identify what the port error is, then maybe i'll have enough info to go to quatech with it.
 
In case anyone is interested, I put the new drivers that includes 64bit in the download section. Now I can start playing with it.
 
I've just been through another bout of instability with the Quatech-connected devices...and it again seems to revolve around wait times. I finally changed the write wait time for my RCS TR-15 driver to 1 sec, and now it seems stable. Prior to that, it was having near constant write timeouts.

Thus I'm wondering, for those who are successfully using the Quatech...what timeouts are you using for read and writes? Anything remotely fast? (under 1 sec)?
 
Well, for things like my HVAC, the Datanab, and the Brultech....a 1 second timeout isn't so bad. But for things like my Ocelot which monitors the doors, that just seems kind of sloppy. Have I just been spoiled with faster response times when everything was plugged into the PC directly? Or is 1 second no unusual for a networked RS232/virtual comm port?

About the only other thing I haven't tried to change is my network setup. Currently, this is how the Datanab is "connected" to my PC:

Datanab->Quatech->Netgear WGR614 Router->Netgear G5605 Gigabit Switch->PC.

Ya, that's a lot of connections...but it still seems silly that I'd have to give it a second to make the trip. I could probably pare it down to 500 msecs and see if it were still stable...but Im' still kinda surprised at how bit of a difference that is from directly connected to the PC.
 
Why is it plugged into the router? Just due to physical layout of everything? I'd see if it can be plugged directly into the network switch and see if that makes any difference.

I still don't have anything permanently connected to mine. I will eventually at my parents house, but haven't gotten that far yet. But everything I've hooked up to it seems to work as expected. Sometimes that is with a CQC driver, othertimes its connecting directly to the device and using some other software or hyperterm to communicate with the devices.

I'm currently connected to a Autopatch 4YDM matrix switch and communicating fine with it. That even includes using the really old YTools for Windows software to configure the matrix switch.

Mine is connected like this:
Code:
			   Device =>Quatech => Gigabit Network Switch => PC
										  ^
										  ||
										Router
 
Ya, just purely because the router was closer to the Quatech than the switch was. If you think putting the quatech directly on the switch would make a diff, then I'll definitely try it.

Are you using the CQC driver for the autopatch, through the Quatech? I checked the driver, and it uses a read timeout of 500 msecs...so I'd be curious if it ever lost connection for you.
 
Can you verify the interface stats of either end of that cable, make sure you aren't running into CRC/collision Ethernet errors. Something like that would make it look like it's working but seriously impact performance. Since this is an older device, chances are that it isn't negotiating the duplex/speed correctly.
 
How do I go about verifying interface stats? I can verify that within CQC there's not CRC errors, as I check for those and they get logged. What's usually happening is I send out a request for data (from the PC) and never gets back a reply.
 
Since the Quatech doesn't let you check the interface stats, I am hoping your router will allow you to check the interface stats. It's usually listed wherever it shows the link speed/duplex status of the connection. It's definitely a good idea to connect the Quatech to the switch, so you can eliminate router performance issues as the culprit.
 
I found a statistics page for the router, and although some of it is a little hard to decipher, the "Collisions" column is clearly labelled, and shows 0.

I'll try bypassing the router. I need to maybe cleanup some of my net connections, as I have a 5-port router, and two 5-port switches all in use down there. Some of those may no longer be in use, maybe I can consolidate.
 
Well, I moved the quatech connection onto the same switch as the PC, and no change that I"ve noticed (did I need to reboot the network devices after that?)

It doesn't seem like a latency issue so much as sometimes the messages don't seem to make it to the device. And of course, I don't know anyway to prove that they DID. But I put a timeout of 2 seconds on asking the datanab for its data, and I'm still getting timeouts. So I really don't think it's a matter of waiting for the reply message longer.

Because I'm just polling these devices, I can always just poll again if it fails the first time....but I hate having to do that when I never had to for a directly-connected device. And I'm more concerned for a device that sends async messages that I might miss one, and never know it.
 
Did you ever get in touch with Quatech? This really doesn't sound right. Wish I could test this for you, but I don't have ALC or Datanab.
 
Back
Top