Program that can log from many multimeters.

[HKJ]

So far nothing I have tried has the buttonsOn indicator changing.  So, what am I missing?? 

I am misleading you, my last post was not correct.
You need the :readmath: line and also a :string: line

[gby]

Thank you.  Adding the readmath back and adding the :string: tag got the indicator light to sort of work.  I then debugged it that the device wasn't indicating a changed state right away and that confused the indicator light.  Adding :updatedelayed: 0.1 fixed it.  So the working control, indicator is now:

Code: [Select]

#cmdSetup buttonsOn Axis1_Enable
:string:
:read: AXIS1.ACTIVE?
:readmath: getElement("AXIS1.DIS AXIS1.EN",value)
:write: txrx #
:tip: Disable (Off) or Enable (On)
:color: (0,255,0)
:updatedelayed: 0.1
:updatealloff:
Off AXIS1.DIS
On AXIS1.EN
I will work on some more popup controls and then look at the creating an interface for it.

[gby]

HKJ,

I am following your suggestion to use #verifyDevice given this device does not accept *IDN?.  I can get it to work inserting an exact string in for value for a specific model device.  However, there are multiple model numbers that need to match.  So, I tried putting expressions in for #verifyDevice value and adding :readmath: after the #verifyDevice line.  All these tries led to Java null pointer errors.

Is it possible to use #verifyDevice with an expression manipulating the returned value from the command such as match(<returned value>,regEx)?

[HKJ]

HKJ,

I am following your suggestion to use #verifyDevice given this device does not accept *IDN?.  I can get it to work inserting an exact string in for value for a specific model device.  However, there are multiple model numbers that need to match.  So, I tried putting expressions in for #verifyDevice value and adding :readmath: after the #verifyDevice line.  All these tries led to Java null pointer errors.

Is it possible to use #verifyDevice with an expression manipulating the returned value from the command such as match(<returned value>,regEx)?

You cannot use expressions with #verfiyDevice, but you can use :readmath: with #scpiCmd.

The idea is that you have a separate #metadef and for each device type. This #metadef will replace the #verifyDevice line. In the current version you can only do it with #replacetext, but from next version it will be possible to do direct replacement, i.e. simply add a #verifyDevice in the #metadef section.

If you really need a more flexible way to compare, I will have to look at adding regular expressions support to #verifyDevice. It can be a bit hard to learn, but it is extremely flexible way to match.

[gby]

Clever idea to define a new #scpiCmd to use in the #verifyDevice with the required manipulation of the returned value in the new command.  I did that and it worked fine.

The only problem I had was all kinds of Java exceptions when using the :readmath: match(value,regEx).  Whatever regEx I put there just did not work.  Then I tried putting the regEx in quotes and that worked fine.  You might want to update the doc for the match(value,regEx) string function to mention using ""'s or have an example like what I ended up with:

   :readmath: match(value,"Drive.*AKD2G-...-.V..S-.*")

On to figuring out how to use this info to change available functions/commands/popup controls.

[HKJ]

The only problem I had was all kinds of Java exceptions when using the :readmath: match(value,regEx).  Whatever regEx I put there just did not work.  Then I tried putting the regEx in quotes and that worked fine.  You might want to update the doc for the match(value,regEx) string function to mention using ""'s or have an example like what I ended up with:

All the languages I am used to need RegEx in quotes, but you are correct that it is a good idea to include it in the documentation.

If you start playing with #metadef you will need the new version, please say when you need it and I will post a .jar file. The two changes are optional sections in a definition and #verifyDevice can be directly replaced.

[HKJ]

It may also be a good idea to define these two commands:

#scpiCmd getDeviceSW? ...
#scpiCmd getDeviceSN? ...

They are used to build a full *idn? answer with serial number and software version. This information is also used in the TestController popup with connected equipment.

[gby]

I will be working some more tomorrow, over the weekend.  I have plenty to do without an updated version and new features.  But, if it is ready I can start taking a look at it.

[HKJ]

I will be working some more tomorrow, over the weekend.  I have plenty to do without an updated version and new features.  But, if it is ready I can start taking a look at it.

As long as no one need the improvements (It is only relevant for a few people), I will wait a bit with the next version, until I have something more.

[fragile]

Is it cross platform? It sounds like you've put a lot of effort into this! I can't even imagine how to do something like you've accomplished. At my school we can use  visual studio. Do you use that?

[HKJ]

Is it cross platform?

Being in Java the answer is yes, but USBHID interface is not.

It sounds like you've put a lot of effort into this! I can't even imagine how to do something like you've accomplished. At my school we can use  visual studio. Do you use that?

Java is not tied to a specific development platform and I have avoided using platform specific tools, i.e. I can use any Java development platform I wish and easily switch to another platform (I use Eclipse).

[PushUp]

Have you changed something with the USBHID within 0.96?

When using my Brymen 867 (haven't checked my Elma 829s so far) it is not recognized with version 0.96 anymore.

However, versions 0.94 and 0.95 are still fine?!

Just for curiosity:
My Win7 is always offline, having no network connection at all, but TestController always shows "New Version", when using it? Is there a way to change it?

Thanx! 

[MikeLud]

Have you changed something with the USBHID within 0.96?

When using my Brymen 867 (haven't checked my Elma 829s so far) it is not recognized with version 0.96 anymore.

However, versions 0.94 and 0.95 are still fine?!

HKJ

Same here my BM869s does not work with V0.96

[HKJ]

Have you changed something with the USBHID within 0.96?

When using my Brymen 867 (haven't checked my Elma 829s so far) it is not recognized with version 0.96 anymore.

I change my 7 segment decoder to also support two words for a digit. I will fix it, probably tomorrow.

My Win7 is always offline, having no network connection at all, but TestController always shows "New Version", when using it? Is there a way to change it?

I will also take a look at this.

[ArsenioDev]

After trying a bunch of variants on the file I cannot get it to even get a hello from the Korad power supply :|

[HKJ]

After trying a bunch of variants on the file I cannot get it to even get a hello from the Korad power supply :|

If the sigrok description is corrent, I need to make a new driver before it will work:
https://sigrok.org/wiki/Korad_KAxxxxP_series

The problem is missing line terminations, this means all communication must terminate with a timeout and I do support that at the current time.
This sound rather silly, maybe it uses a space for ; for terminations?

[HKJ]

V0.97 is up
It is a bugfix for Brymen, includes the new section possibility in definitions, adds two lux meters and a very advanced servo
   Added Kolmorgen servo by gby
   Added Gossen M5032 Lux meter
   Added UNI-T UT382 Lux meter
   Do not show "New version" when offline
   Restored Brymen multimeters, I had a error in V0.96 preventing them from working.
   Sections in definitions file for use with #metadef. This is an easier way to handle include/exclude of many lines.
   #verifyDevice can be replaced in #metadef


Debug of serial will list buffer data on timeout, I hope this help with figuring out the Korad termination

[gby]

HKJ,

I have a device which uses Modbus TCP communications.  I see the website lists Modbus RTU support and see it is used in the Maynuo M97 and RidenRD60 definitions with port com.  Just to see if it would work I made a definition file with port 502 which is the default Modbus TCP communications port like the below:

Code: [Select]

#idString Kollmorgen,AKD1G,Modbus
#name Kollmorgen AKD1G Servo
#handle AKD1GModbus
#port 502
#driver ModbusUsing Version 0.97 the result when trying to connect is just Java runtime errors.

Code: [Select]

Starting
Exception in thread "Thread-2" java.lang.ClassCastException: dk.hkj.comm.SocketInterface cannot be cast to dk.hkj.comm.SerialInterface
        at dk.hkj.devices.DeviceModbus.getCommInterface(DeviceModbus.java:496)
        at dk.hkj.main.InterfaceThreads$DeviceThread.<init>(InterfaceThreads.java:899)
        at dk.hkj.main.InterfaceThreads$ScanPorts.addDevicesSocket(InterfaceThreads.java:500)
        at dk.hkj.main.InterfaceThreads$ScanPorts.run(InterfaceThreads.java:613)
Does TestController support Modbus over TCP?  If it does what is a proper header definition?
If it doesn't, then how hard would it be to support Modbus TCP?

[HKJ]

Does TestController support Modbus over TCP?  If it does what is a proper header definition?

No, I only support RTU.

If it doesn't, then how hard would it be to support Modbus TCP?

No, the problem is testing. I do not have anything that support Modbus TCP.
My drivers can support line and/or binary protocols. Serial support both, TCP only support line and I would need to add binary support.
I would also need to add another modbus frame format.

Modbus could also use Modbus Ascii on a TCP/IP connection, that would have worked with my line TCP driver, but would still need another frame format.

[gby]

HKJ,

Ah, not having a device to test with does make development hard.  If you want to try I could be your test case.

[HKJ]

Ah, not having a device to test with does make development hard.  If you want to try I could be your test case.

I am up to it, but it will probably take many versions and a lot of time to get it working. You can look back to some of the other that have been done remote.
But first: Do you have any documentation of the modbus format for your device. I want to be sure it is modbus TCP/IP and not modbus ascii (That is considerable easier, because I can use the line based protocol).

Before I can start on it I will also need to be finished with the current addition to TestController, but that will probably be finished today or tomorrow.
It is trigger modes for logging: StartStopOnCommand, SingleOnCommand, SingleOnTrig, WhileTrig, StartOnTrig, StopOnTrig

I also have one question for the triggering modes: The onCommand is designed to control logging from a script, but they could also be controlled from a popupWindow, do anybody see any usage for that? (I.e. starting/stopping logging from a small popup window, it will add to the same table).

[gby]

There should be full doc for the Modbus TCP Interface.  I will switch to pm to send links and/or files for the doc to not clutter up the main thread.

[MikeLud]

I also have one question for the triggering modes: The onCommand is designed to control logging from a script, but they could also be controlled from a popupWindow, do anybody see any usage for that? (I.e. starting/stopping logging from a small popup window, it will add to the same table).

HKJ,

What would be a nice to have if you can make the scripts as a device file like the VirtualxxxxxGenerators, we can then make a button to do the triggers manually.

Also one of the new versions broke the RD60xx device file, attached is the fix.

 RidenRD60xx.txt (7.3 kB - downloaded 39 times.)

[HKJ]

What would be a nice to have if you can make the scripts as a device file like the VirtualxxxxxGenerators, we can then make a button to do the triggers manually.

It would be easy enough to add a VirtualGenerator base class, but doing that for triggers would be silly.
The option for triggers is a small one-top window that can be used to start/stop logging or take a single sample when a button is pressed, depending on trigger mode.
The "Trig" modes use a expression to trigger where you can use any logged value (But not calculated/Math values) or date/time to control triggering.

Also one of the new versions broke the RD60xx device file, attached is the fix.

Please specify what the problem is, I had to compare files to find the change.
I wonder. I had a problem that I did not set the baudrate in some cases, could that be the issue and it now works at 115200.
Please check.

[MikeLud]

Please specify what the problem is, I had to compare files to find the change.
I wonder. I had a problem that I did not set the baudrate in some cases, could that be the issue and it now works at 115200.
Please check.

HKJ,

The issue had nothing to do with the baudrate. The issue was when setting the below variable, I had to set it as an int, before I did not.

I did test the newest version at 115200 and it still has the intermittent timeout

Code: [Select]

#scpiCmd MN? holding? 0x80
:setvar: MNS=int(value)