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

Through a bit of reverse engineering and an old Laptop running Win XP and Network Monitor 3.4, I've discovered a number of issues, but now have it working over LAN with a plugin I have written for my automation test suite. It basically uses raw UDP packets for both discovery and command/query. The discovery is done on port 18191 and the command/query is on the port you set (default 18190).

The Test Connection tool basically uses INET_BROADCAST (255.255.255.255) which doesn't work on anything newer than WinXP SP3, unless your luck and the first network adaptor in your PC is handling the broadcast. If not, then the adaptor doesn't forward it on to the network! Tried altering static routing i my Win7 Pro machine, but that made no difference. The answer is to query the adaptor for the net-mask and create the broadcast address based on that plus your local host IP address (i.e use the subnet-broadcast for the active adapter).

Has been reported to both Farnell tech support and KORAD support, so hopefully, they fix that one!

The use of UDP for remote control commands seems a bit unusual and potentially unreliable (although, in reality on a non-congested network it probably will work okay). Not the best design and not something I've seen before - what a surprise!

- Gough

Broadcast address forwarding was quite ubiquitous until a few years ago. In a test equipment connected to a network segregated from the internet, I think that safety concerns can be minimized.

My guess is that the firmware was tested only with Windows XP and never touched again. Hopefully they address this, but TBH I wouldn't hold my breath.

Some details about broadcasting on Windows XP and 7 that may be interesting:

https://social.technet.microsoft.com/Forums/windows/en-US/72e7387a-9f2c-4bf4-a004-c89ddde1c8aa/how-to-fix-the-global-bro…

I agree that it is very unusual to use UDP but  I think it is the ideal protocol to support SCPI style commands.

Pretty much everyone else uses TCP/IP and sockets, which is a streaming protocol and a fairly poor fit with the discrete message format of SCPI. In order to support the features of TCP/IP they frequently end up with a complex OS on an instrument with no other need for it - with all the attendant problems of maintenance and security..

A really good reason for using just UDP is the simplicity possible in the test gear software - this can be used to achieve very fast performance (not relevant in this case) or very low cost of implementation (probably why used in this case) or very good stability/predictability/security of the software.

It is a great shame that the Tenma PSU isn't better documented - that seems to be the biggest shortcoming and it would be so cheap an easy to put right.

MK

Its certainly easy to implement and as every command (which has no response) has a matching query (returns the set data), so its easy enough to write then query the setting to ensure its been received and set.

I agree the documentation is a joke. Much of it doesn't make sense and the examples in the 'steps' don't reflect what you would see on the display. I've figured it all out by writing my own LAN application and 2 days playing around with the unit to work out exactly how the battery and pulse functionality works and the manual does not reflect what it does or can do!

<rant>

Element14 need to step up their game if they want to take a product and slap their brand on it. Documentation is useless, software does not work out of the box (unless you have Win98 or WinXP!), No USB drivers supplied and the ones that have been by support and KORAD still don't work and the lack of documentation regarding the programming is diabolical.

I've essentially had to reverse engineer a brand new product in order to get it working for me! I say brand new, but it has been out as the KORAD KEL-103 since last year and passed its EMC for export back in Dec 2017 ... so its not new, its a mature product!

</rant>

I agree that UDP is much simpler in implementation, and could be faster (which is one reason I do use it for some data acquisition tasks), but if we account for all the nasty things UDP could have happen to it, then it's not so clear, especially if sending SCPI commands over the link.

For example, if we are sending an enquiry, then that's no big deal as we know if it succeeded depending on whether a reply was received. No reply, retry again.

But some other SCPI commands are more problematic - for example, setting a parameter where no reply is expected. You could query the device to check the present value, but that now adds overhead which you wouldn't have with TCP as you know the device has got it based on packet-level acknowledgement. Likewise, unlike GPIB, there is no dedicated lines for the instrument requesting attention from the host (SRQ), so if this is being emulated over UDP, there's a chance that such requests could go missing.

Another issue is that UDP could be dropped/re-ordered in transit and does not guarantee any reassembly order. Perhaps the instrument is streaming a chunk of data back to the machine that spans multiple packets. If anything gets reordered, your data will probably be hosed depending on what format it is. Other times, maybe you need to rapid-fire configure the device through setting mode, setting values, etc - if the instrument receives the commands in the wrong order, then it may not accept the command as it's not in the right mode.

While TCP is heavier, there are chips with basic TCP stacks onboard and it can be handled by some low-cost micros without great difficulty especially when we're talking about a device that may need to be configured only occasionally and have read-outs every second or so. It adds peace of mind that things remain ordered and that commands are sent or received as expected. With the lack of state on UDP-based connection, the instrument could be lost/powered down and the software has no timely way of knowing except to retry and time-out after not hearing a response.

Of course, for something simple like this, I don't see it as a major problem, but I'd rather things stick with the "standard" so as to avoid making integration more difficult than it should be. I have a set of power supplies that use AT commands for configuration, but without line termination ... instead detecting the end of a command through a time-out. Needless to say, this was a rather annoying thing to get used to ... I very much prefer my USB-TMC/LXI-LAN capable PSU over that.

- Gough

cstanton  Hi Chris, Are you able to get one of your colleagues to provide drivers and USB installation instructions for Simon?

Hopefully it's not a tricky one where one has to install the USB drivers prior to plugging in for the first time.

Thanks!

Compact

> Hi Chris, Are you able to get one of your colleagues to provide drivers and USB installation instructions for Simon?

The stellar efforts by the persons involved in this thread has practically exhausted every avenue I can already attempt.

Being a TENMA it's an Element14 product.

Can you contact your purchasing dept or TENMA branding dept to contact the actual manufacturer?

To simplify access for TENMA and other e14 brand support can e14 provide a tech support download page?

You are not quite clear here:

 

Another issue is that UDP could be dropped/re-ordered in transit and does not guarantee any reassembly order. Perhaps the instrument is streaming a chunk of data back to the machine that spans multiple packets. If anything gets reordered, your data will probably be hosed depending on what format it is. Other times, maybe you need to rapid-fire configure the device through setting mode, setting values, etc - if the instrument receives the commands in the wrong order, then it may not accept the command as it's not in the right mode.

 

In an RFQ compliant system:

A multi fragment UDP will be received complete, fragments in order or not at all.

UDPs may not be received in the order they were transmitted.

There is no re-assembly of packets. Of course if you devise a multiple UDP protocol it's up to you to keep the messages in order (in real life I've NEVER seen a single switch re-order UDPs, although I've often seen them dropped.) If you sent such messages to a remote location through complex routes and multiple routers it can happen. The implication of this is that your top level protocol must deal with out of order UDPs but in sensible case this is not very hard to do.

SCPI is not the ideal high level protocol for UDP (or TCP/IP) (or probably anything else but it's what we are stuck with.) Instruments quite often seem to ignore commands, so regular status checking as Simon describes is a good plan even when TCP is used.

In real life I've had fewer problems with UDP based systems than with TCP/IP, but I agree that it's a pain when one manufacturer goes a different way from (nearly) all the others.

MK