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

I've got a copy of the CD supplied with the KORAD KEL-103 (direct from KORAD support) and the 'USB driver' is under 'Software'. (Attached). Sadly, it doesn't do anything to improved the USB situation !!!

I've also queried why there are 2 devices shown in the device manager and why the LAN doesn't work with the Assistant application, still waiting on feedback.

Not heard anything from the 2 support chaps at Element14 that I reported the issues to yesterday and the day before! NOT IMPRESSED!

Simon.

UPDATE 20/09/2018 @18:47 :

Hey, I discovered why the LAN discovery tool doesn't work! They discover the devices by broadcasting a UDP message with the string 'find_ka000' on port 18191.

However, they use the IP address of 255.255.255.255 as the broadcast address. THIS DOES NOT WORK! They need to work out the broadcast address from the hosts IP address (your computer) and the network mask.

Examples :

Host IP = 10.0.0.56, Mask = 255.255.255.0 -> The broadcast address = 10.0.0.255.

Host IP = 10.0.0.56, Mask = 255.255.0.0 -> The broadcast address = 10.0.255.255.

255.255.255.255 would only work if your network mask is 0.0.0.0.

The device then returns a UDP packet from each of the discovered device IP's to the host IP which contains a 48 byte long payload of...

IPAddress<0x0A>MACAddress<0x0A>DevicePort<0x0A> and padded out with zeros (0x00).

Example :

10.0.0.200<Linefeed>7f-45-12-cd-89-a2<Linefeed>18190<Linefeed><Zeros>

At least I'm half way to writing my own app to communicate over LAN :-)

I'll relay this to KORAD tomorrow and see what their response is!

I've got a copy of the CD supplied with the KORAD KEL-103 (direct from KORAD support) and the 'USB driver' is under 'Software'. (Attached). Sadly, it doesn't do anything to improved the USB situation !!!

I've also queried why there are 2 devices shown in the device manager and why the LAN doesn't work with the Assistant application, still waiting on feedback.

Not heard anything from the 2 support chaps at Element14 that I reported the issues to yesterday and the day before! NOT IMPRESSED!

Simon.

UPDATE 20/09/2018 @18:47 :

Hey, I discovered why the LAN discovery tool doesn't work! They discover the devices by broadcasting a UDP message with the string 'find_ka000' on port 18191.

However, they use the IP address of 255.255.255.255 as the broadcast address. THIS DOES NOT WORK! They need to work out the broadcast address from the hosts IP address (your computer) and the network mask.

Examples :

Host IP = 10.0.0.56, Mask = 255.255.255.0 -> The broadcast address = 10.0.0.255.

Host IP = 10.0.0.56, Mask = 255.255.0.0 -> The broadcast address = 10.0.255.255.

255.255.255.255 would only work if your network mask is 0.0.0.0.

The device then returns a UDP packet from each of the discovered device IP's to the host IP which contains a 48 byte long payload of...

IPAddress<0x0A>MACAddress<0x0A>DevicePort<0x0A> and padded out with zeros (0x00).

Example :

10.0.0.200<Linefeed>7f-45-12-cd-89-a2<Linefeed>18190<Linefeed><Zeros>

At least I'm half way to writing my own app to communicate over LAN :-)

I'll relay this to KORAD tomorrow and see what their response is!

If Korad is using a Dual RS-232/USB device (such as FT2232), then I would have expected to see two ports there. In the drivers directory, is there any .inf file? Perhaps you could try to find what are the driver files used (if it is something like ftdi*.sys or dll)

I suspect the OEM never cared to test/implement this functionality, or the precise model was not supposed to have programmability enabled (another thread comes to mind in this regard, where minimal changes on the model number make the whole difference). That or the manufacturer forgot to flash the microcontroller or USB bridge IC that performs this functionality.

At any rate, good luck with your investigation.

They don't use a USB to UART converter (like FTDI), the USB DP and DM go straight into the STM32F107 microprocessor, so all the USB is hosted in the application firmware.

For info, they also seem to use a Texas Instruments DP83848 Transceiver for the LAN PHY and the Ethernet stack is also in their application firmware.

I have Element14 sending me another CD, so we'll see what that has to offer!

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

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

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

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