Need Windows USB Driver for TENMA 72-13210 (electronic dc-load 30A/120V 300W)

COMPACT , reading the thread above, it appears this has/is already being attempted via contacting Technical Support who have the appropriate contacts to do that.

element14 provides a limited technical support for the products that are distributed, and technical support requests for the products are monitored, assessed and reacted to via the technical support live chat, support and similar channels on the online store website.

The community team, nor social media team, have access to the system that the technical support use to monitor and log problems and reports of problems so it is the best way to try to get support like this so it's logged and fed back to the product managers, purchasing department, etc.

Already spoken to Element14 support on numerous occasions and they supplied a new CD which still doesn't address the USB issue.

I spend 3 days last week talking to KORAD (the manufacturer) and they were very supportive (supplied the CD image for the KEL-103) up to the point where I described the 2 devices in device manager (SZ KORAD USB Mode) and the LAN discovery tool not working on Win7/Win10. At that point they have stopped responding. I suspect they have had an oh s**t! moment and are currently trying to address the problems ... or at least you hope so!

This should have been sorted out by Element14 quality and support BEFORE being released to customers!

A multi-fragment UDP would be a single transmission that contains more than the maximum payload for a single packet (MTU - headers). However, there is a size limit to even this fragmented UDP of about 64kB. As it now requires multiple packets to make it in transit for an "all or nothing" scenario, it is a bit risky.

However, some instruments may return their data one line at a time (e.g. a matrix data dump from a VNA) which if it exceeds this size, would (theoretically) require either multiple UDP transmissions (each which could suffer re-ordering or dropping). Likewise, when sending SCPI commands, unless you are concatenating multiple commands into a single "line" using the semicolon, each command may be sent in its own transmission, occupying a single packet at a time. I tend to prefer sending each line separately (e.g. "TRIG:SOUR BUS" and "RANG:DC:AUTO ON" being two separate messages for example) as some instruments have very limited buffer room for parsing commands - if each of these are sent in separate UDP packets, there could be reordering as a result.

I've seen packets dropped and I've seen them reordered but only under very specific scenarios. One way this can be achieved is when the packets have to traverse a stressed routing queue into a router which may have load-balancing across several paths to the same destination. Very unlikely for most applications, but still a possibility.

Status checking is always a good idea but one I rarely use it out of laziness Something I should probably change I've never had too many dramas with TCP/IP aside from occasional hiccups due to transport layer packet drops and retries but that's by design I like UDP too especially for streaming raw data where losses won't matter But doing remote commanding just seems somewhat non-ideal But then again  RS-232RS-232 never had any acknowledgements either .

- Gough

I think it's easy to get lulled into a false sense of security when talking to instruments in a lab - on a nice small, fast and closed network everything Ethernet works really nicely and the reserve capacity is huge. I find that in my own lab sending a UDP to an instrument is just as reliable as using a direct wired connection - but put that same thing out on decent sized factory's network and it's a different story.

I see you are about to play with the Hameg/RS 4 channel power supply -  it seems to be SCPI over TCP. Their example code illustrates the problem you mentioned -

they use INST OUTx to select channel

and then maybe set the current using CURR i,

check with CURR?,

and it replies with i,

if it missed the INST OUTx you would have set and checked the current on an unknown channel.

MK

Totally agree. I even get away with running sensors on UDP from ESP8266 boards over Wi-Fi and maybe see one or two lost packets a day on a one-packet-per-second rate. It's especially nice when sending to broadcast to allow multiple network users to access the latest readings from my outdoor weather station. When I bought the same prototype to a busy hospital - aside from being kicked from the APs due to deauthentication to protect from rogue wireless devices, even inside meeting rooms, the interference was enough to cause noticeable loss of packets. I've also met some consumer Wi-Fi gear that couldn't handle high rate UDP in any way - 7 packets per second was all it would do before choking up. No wonder I couldn't get any VoIP working over that unit!

The Hameg/RS supply should very much be capable of standard SCPI direct (5025/TCP). I guess checking helps, but so does concatenating commands so (hopefully) the instrument either gets the whole batch and actions it, it gets lost in transit entirely, or it "beeps" (or something to that effect) and logs a SCPI error to say it's not happy. Something akin to sending "INST OUT1;CURR i" should be valid SCPI syntax, albeit one I've never tried until I thought about this issue just now!

Thanks for the discussion though - I think we both agree that it's odd but for many cases, UDP will work although.

- Gough

Keep chasing it up. It's possible that it's fallen off their radar.

Korad's download tab for the DC Load on Korad's website is empty (& main URL koradtechnology.com seems not to exist).

I had to download the manual from another source.

Unless your problems are sorted out promptly you should be able to return the product because it is "Not fit for purpose".

I fanned through the manual an it says nothing useful about the USB interface nor how to install the drivers. It says "Please refer to the Communication Protocol." which is ambiguous and meaningless.

It's pretty disappointing considering I'm currently happy using a Korad (TENMA) PC programmable power supply with USB and RS232 interface.

For highest quality customer service there's a saying that sums up the actions that should be followed: "TOFU - Take Ownership and Follow Up for your customers irrespective whether it's your area's responsibility or not."

What you have experienced should not occur with one let alone two ISO900x accredited companies.

BTW - These DC Electronic Loads are on special at e14 in Oz at the moment. Are you going to buy one Gough? Or will you hold off until Simon's problem is sorted.

Thanks for the heads up. Tried to get to e14's page but it seems everyone on this Telstra IP-block has been blocked tonight. Not good.

No worries, checked it out via my secondary WAN over Optus. Slow as usual, but at least I got the page. Indeed quite a very tempting price ... but I think I'll pass. The issues seem to detract from the desirability somewhat, but aren't exactly insurmountable. The biggest reason is that I have a B&K Model 8600 already thanks to a RoadTest and that one seems to serve me just fine over USB-TMC .

- Gough

So this may be a bit obvious but I have to ask.

You've tried running the setup.exe listed with CD contents ...??

It seems there are various msi and cab files which are windows based files to load something.

Mark

The setup.exe just installs a NI Labview application to drive the Load remotely. But it only supports RS232 and USB (not LAN) and does not install any USB drivers, so the USB doesn't work on that application either. It does install a 2014 Labview core and VISA libraries, but the application doesn't actually use those!

I have had an email from KORAD support saying that they have just supplied Farnell Tech Support with a solution. I don't know if thats the one that Farnell sent to me last week or something newer based on the detailed information I have supplied. If it's the one I got last week, that doesn't work either, so we'll wait and see if Farnell come up with something newer that finally addresses this.

Oh ...

I've found hat the PID and VID direct Windows where to find the details for a device.

Obviously it isn't working and most likely because of the hoops Windows would make the vendor jump through.

Typically you can tell Windows that you're installing a generic device, and choose Com Port/Modem, which then allows you to get down to the actual file, but in your case it looks like the ini file isn't there.

You can often default it to a COM port, and it will simply behave as one, but you'll need to set the speed.

It's strange they have these two entries

³   ³       Microsoft Windows Driver Kit License - English.rtf

³   ³       OPC Classic COM License - English.pdf

Hopefully they have a more user friendly solution.

Mark