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

[mustangcoupe]

Thanks purple_motion

Actually the seller took it back for a replacement. We beleive I might have had bad hardware because on power cycle it appeared to go through a reset like if you held the button down.

I will have it tomorrow, and hopefully get a chance to test it right away.

 

[beelzerob]

Well, I woke up this morning to the dreaded blink-field syndrome, which in CQC means some driver isn't happy. Turns out a lot of the drivers weren't happy. My OnQ ALC controller isn't responding at all, my RCS TR-15 driver was having trouble writing data, and I forget what else.

I pulled/plugged power on the ALC, the Quatech, the router, and the two switches that are all a part of the network, and nothing improved. I didn't have a chance to pursue it further this morning, but I just can't take this instability anymore. I think I'm back to plugging in the Moxa card and seeing what devices it does and doesn't work with. It REALLY sucks because I had already trimmed many-a cable so it would only have to reach the Quatech, not all the way to the rack.

 

[beelzerob]

Just for fun, I tried the dlink power supply I had laying around, to see if somehow the HK power supplies I got weren't sufficient. After a little time, it appears that there is no difference.

I'm not sure yet, but I *think* that if I reboot my PC, then the issue of "sending messages but getting no response" appears to fix itself. So that would seem to make it a virtual comm port driver issue, or at least, maybe not the quatech box itself.

I think my next step will be to replace the quatech box with another one and see if there's a diff.

 

[beelzerob]

Hmmm...not to jinx it, but I switched the Quatech with a different one, and so far, no disconnects.

Other than being different devices, the other difference I know of is this working quatech doesn't have the firmware update, and I also didn't configure the ports for low latency. So, if this one works for a long time, I think I'll swap back in the suspected one, and if it's still flaky, then I'll try switching the low latency option back to balanced and see if that makes a difference.

 

[beelzerob]

Well, looks like the bad numbers (disconnects, lost comms, failed writes) are starting to creep up again. it still seems *better* than it was, but still not acceptable.

So, since I seem to be the only one who is having this much trouble with this many devices, I'm beginning to hope/think it must be the stuff inbetween the quatech and the PC. Currently there is a router, and 2 switches, all netgear, in the mix.

I know I have a spare network card somewhere, so what I'm thinking of is putting that in my PC and plugging the quatech directly in there. Kinda defeats the purpose of the networkedness of the quatech, but strictly for testing purposes, that should establish if the problem is the network hardware.

 

[wlj]

So, since I seem to be the only one who is having this much trouble with this many devices, I'm beginning to hope/think it must be the stuff in between the quatech and the PC. Currently there is a router, and 2 switches, all netgear, in the mix.

You're not the only one who's having issues with the Quatech devices. I've got two, and neither provide a reliable connection to my ALC SLI controller or another device I was hoping to connect. I've tried everything I can think of (firmware, latency, virtual port drivers, direct connection using cross-over cable, etc.) and see a significant number of ALC protocol errors. I've concluded that the Quatech simply isn't usable with the (my?) ALC SLI controller. I certainly like to find a solution, though.

The Quatech does seem to work OK with my Ocelot, and a few other serial devices that I've tried.

Cheers,
-Bill

 

[beelzerob]

Interesting, and good info. I'd say the ALC is definitely the most affected. The Ocelot appears to work, but I do get the occassional "failed write". It seems to happen so rarely that it's not a *big* problem, but it does mean I'm not always getting the input data as fast as I should be. Since the Ocelot monitors my doors, I'm not happy about the idea of it missing the fact that a door has opened, if even for a second.

I think for sanity's sake, I'm going to have to plug it all back into my PC directly and make sure it really is a network/quatech issue.

 

[wlj]

I think for sanity's sake, I'm going to have to plug it all back into my PC directly and make sure it really is a network/quatech issue.

I should add that I've not had any problems with my ALC SLI or the other problem device when connected directly to a standard hardware serial port or my Edgeport 8-port USB->Serial box. To rule out software as a problem, I've been using OnQ's ALC SceneTech software to drive the ALC SLI controller for test purposes. This, too, generates errors when the ALC SLI is connected via the Quatech. No errors are generated when my custom software or SceneTech are connected to the ALC SLI via hardware or Edgeport serial ports.

Cheers,
-Bill

 

[mustangcoupe]

Did you guys install the Quatech drivers or are you using another virtual comm port program?

 

[beelzerob]

I only used the Quatech stuff, from running that wizard.

 

[wlj]

Did you guys install the Quatech drivers or are you using another virtual comm port program?

I've experienced the same unacceptable results with my ALC SLI controller using both Quatech and third-party virtual comm port drivers under 32-bit Windows XP SP3. The driver didn't seem to make any difference. I've also tried every configuration setting in the Quatech that was available with the various drivers. I've had marginally better 'success' with the Quatech 'low latency' setting, but that still results in far too many errors to be usable.

Cheers,
-Bill

 

[mustangcoupe]

hmm, just trying to weed out a driver issue

 

[beelzerob]

Well, after a day on the new device I can say it's just as bad.

The ocelot is showing 40 failed writes. The RCS TR-15 has 9 lost comms, and the ALC has 14 lost connections. I'll have to go into the code to see what all of those mean as far as what affect this is having...it could be that with a little redundancy (checking for SURE that the message arrived), it could be liveable.

But before that, I'm going to resurrect my Moxa card and get them all plugged into the PC directly as a baseline. it might be that they were all behaving this badly before but i never noticed. I find that very unlikely, but still....

If it does end up being the quatech, undeniably....I'm probably going to have some to sell.

 

[electron]

Bob, have you tried contacting Quatech support? If it is the Quatech, it has to be some sort of bug, and maybe they would be willing to fix it.

 

[beelzerob]

Hmm...didn't think about asking for help from them, since these are older units and bought 2nd hand. But worth a shot, I guess.

For now I'm still collecting results. I plugged the 3 worst offenders directly into the PC last night, and as of this morning, the ALC had 1 disconnect, but the others were JUUUST fine.

Aren't lots of you guys using your Ocelots with this thing too? Because the Ocelot had repeated problems with "failed writes". I don't know if you guys are able to track that kind of stuff or not, so maybe you wouldn't be aware if it was occassionally failing. If it weren't for the failed writes counter, I probably would have no idea the Ocelot was having issues. So, just curious if anyone else can evaluate their ocelot in that regard.