Program that can log from many multimeters.

[HKJ]

I does work on the command line

I am a bit lazy tonight and am not going to test it, but could the problem be you use:

#scpiCmd xxx holding? 0x123 /100 (value)

and not:

#scpiCmd xxx holding? 0x123 (value) /100

[MikeLud]

HKJ,

I have most of everything work except when trying to writing a new VSet or ISet value I get the below code.

Code: [Select]

;; RD6006: Rx as number <1.0>
;; RD6006: Tx <VSet?>
;; COM7: Tx: 01 03 00 08 00 01 05 C8
;; COM7: Rx: 01 03 02 01 F4 B8 53
;; RD6006: Rx <5.0>
;; RD6006: Rx as number <5.0>
;; RD6006: Tx <ISet?>
;; COM7: Tx: 01 03 00 09 00 01 54 08
;; COM7: Rx: 01 03 02 04 D2 3A D9
;; RD6006: Rx <1.234>
;; RD6006: Rx as number <1.234>
;; RD6006: Tx <VSet 5.67>
java.lang.NumberFormatException: For input string: "*100"
        at java.lang.NumberFormatException.forInputString(Unknown Source)
        at java.lang.Long.parseLong(Unknown Source)
        at java.lang.Long.parseLong(Unknown Source)
        at dk.hkj.devices.DeviceModbus$TranslatingCommInterface.parseLong(DeviceModbus.java:43)
        at dk.hkj.devices.DeviceModbus$TranslatingCommInterface.parseValuesLong(DeviceModbus.java:161)
        at dk.hkj.devices.DeviceModbus$TranslatingCommInterface.write(DeviceModbus.java:255)
        at dk.hkj.main.SCPICommand.writeReadInternal(SCPICommand.java:212)
        at dk.hkj.main.SCPICommand.writeRead(SCPICommand.java:249)
        at dk.hkj.main.SCPICommand.write(SCPICommand.java:281)
        at dk.hkj.devices.SetupFormats$NumberField.actionPerformed(SetupFormats.java:831)
        at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
        at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
        at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
        at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
        at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
        at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
        at java.awt.Component.processMouseEvent(Unknown Source)
        at javax.swing.JComponent.processMouseEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
        at java.awt.EventQueue.access$500(Unknown Source)
        at java.awt.EventQueue$3.run(Unknown Source)
        at java.awt.EventQueue$3.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
        at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
        at java.awt.EventQueue$4.run(Unknown Source)
        at java.awt.EventQueue$4.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
;; RD6006: Tx <VSet?>
;; COM7: Tx: 01 03 00 08 00 01 05 C8
;; COM7: Rx: 01 03 02 01 F4 B8 53
;; RD6006: Rx <5.0>

[HKJ]

I have most of everything work except when trying to writing a new VSet or ISet value I get the below code.

The /100 or *100 must be last on the line, you error message looks like it was not and there must be exactly one space between arguments (This will be fixed in next version).

[HKJ]

V0.47 is up.
It contains a Modbus protocol driver and the Maynuo M9712C electronic load. I have added a extra debug line for Modbus that shows the translated command line.
Only the 12C from that series included at the moment, the problem is that each load has a model identifier, but the value is not documented.

To get the identifier for other models in the series, select M9712C and try to connect to another model while in debug mode. This will hopefully list something like:

;; **Device do not match** <2>

I need that line and the actual model, then I can add it.
Post it here or use the email address on the about page to send it to me.

[MikeLud]

I have most of everything work except when trying to writing a new VSet or ISet value I get the below code.

The /100 or *100 must be last on the line, you error message looks like it was not and there must be exactly one space between arguments (This will be fixed in next version).

HKJ,

I am still have issues writing. it looks like the problem is that when the command is issued it is sending a float value when it needs to be an integer see examples below.

Code: [Select]

;; RD6006: Tx <VSet 4.56>
;; RD6006: Tx: holding 0x08 455.99999999999994
java.lang.NumberFormatException: For input string: "455.99999999999994"

Code: [Select]

;; RD6006: Tx <VSet 4.5>
;; RD6006: Tx: holding 0x08 450.0
java.lang.NumberFormatException: For input string: "450.0"

Code: [Select]

;; RD6006: Tx <VSet 4.0>
;; RD6006: Tx: holding 0x08 400.0
java.lang.NumberFormatException: For input string: "400.0"

[HKJ]

I am still have issues writing. it looks like the problem is that when the command is issued it is sending a float value when it needs to be an integer see examples below.

I hope it is fixed now:
http://lygte-info.dk/pic/Projects/TestController/TestController.jar

And when listing error dumps, please include more lines of the java exceptions

[MikeLud]

I am still have issues writing. it looks like the problem is that when the command is issued it is sending a float value when it needs to be an integer see examples below.

I hope it is fixed now:
http://lygte-info.dk/pic/Projects/TestController/TestController.jar

And when listing error dumps, please include more lines of the java exceptions

HKJ,

I am able to write now, but I see that holding is sending a 32 bit  value when it needs to be a 16 bit value. It is using  (10 Hex) Preset Multiple Registers when it need to be (06 HEX) Preset Single Register. I think you need to have the below holding commands.

holding 16 bit integer
holding?16 bit integer
holdingF 16 bit float
holdingF?16 bit float
holdingL 32 bit integer
holdingL? 32 bit integer
holdingLF 32 bit float
holdingLF? 32 bit float

[HKJ]

I am able to write now, but I see that holding is sending a 32 bit  value when it needs to be a 16 bit value. It is using  (10 Hex) Preset Multiple Regs when it need to be (06 HEX) Preset Single Register. I think you need to have the below holding commands.

I do not believe there is a 16 bit float, there is not enough bit for it.
The "holding" command will either use  6 or 0x10, with one value it will use 6, except if "#disableWriteSingle 1" is present. "holdingL" & "holdingF" will always use 0x10 because they needs to write multiple values.
If there is two or more values after "holding" it will use 0x10 format.

A note: the 0x10 is not a 32 bit write, it can write from 0 bit to 1008 bits in 16 bit steps.

[MikeLud]

I have most of everything work except when trying to writing a new VSet or ISet value I get the below code.

The /100 or *100 must be last on the line, you error message looks like it was not and there must be exactly one space between arguments (This will be fixed in next version).

It looks like i missed this, if I have /100 or *100 last on the line the writes works fine.

Thanks again for all of the great work you have done with this program.

Code: [Select]

#scpiCmd TEMPC? holding? 0x05
#scpiCmd VSet holding 0x08 (value) *100
#scpiCmd VSet? holding? 0x08 /100
#scpiCmd ISet holding 0x09 (value) *1000
#scpiCmd ISet? holding? 0x09 /1000
#scpiCmd Volt? holding? 0x0a /100
#scpiCmd OPC? holding? 0x12
#scpiCmd OPC holding 0x12 (value)


[MikeLud]

I got time to add a #cmdDelayTime

Something like:

#cmdDelayTime 50

May fix the timeout.

This is V0.46 and only a .jar file.

HKJ,

I am mostly finished with the device file for the Riden RD6006. Intermittently I am still getting Rx Timeout at the default baud rate of 115200 (see below). Do you have any suggestions that would help this issue, see attached device file for the current settings

 RidenRD6006.txt (4.49 kB - downloaded 83 times.)

Code: [Select]

;; RD6006: Tx <values?>
;; RD6006: Tx <holding? 0x08 /100;holding? 0x09 /1000;holding? 0x0A /100;holding? 0x0B /1000;holding? 0x0D /100;holding? 0x21 /100;holding? 0x23;holdingl? 0x26 /1000;holdingl? 0x28 /1000>
;; COM7: Tx: 01 03 00 08 00 01 05 C8
;; COM7: Rx: 01 03 02 01 4A 38 23
;; COM7: Tx: 01 03 00 09 00 01 54 08
;; COM7: Rx: 01 03 02 00 FA 38 07
;; COM7: Tx: 01 03 00 0A 00 01 A4 08
;; COM7: Rx: 01 03 02 00 FD 79 C5
;; COM7: Tx: 01 03 00 0B 00 01 F5 C8
;; COM7: Rx: 01 03 02 00 FB F9 C7
;; COM7: Tx: 01 03 00 0D 00 01 15 C9
;; COM7: Rx: 01 03 02 00 3F F8 54
;; COM7: Tx: 01 03 00 21 00 01 D4 00
;; COM7: Rx: 01 03 02 00 04 B9 87
;; COM7: Tx: 01 03 00 23 00 01 75 C0
;; COM7: Rx: 01 03 02 00 1E 38 4C
;; COM7: Tx: 01 03 00 26 00 02 25 C0
;; COM7: Rx: 01 03 04 00 00 00 69 3A 1D
;; COM7: Tx: 01 03 00 28 00 02 44 03
;; COM7: Rx: 01 03 04 00 00 01 0B BA 64
;; RD6006: Rx <3.3000000000000003 0.25 2.5300000000000002 0.251 0.63 0.04 30 0.105 0.267>
;; RD6006: Delay: 100ms
;; RD6006: Rx as numbers <3.3000000000000003 0.25 2.5300000000000002 0.251 0.63 0.04 30.0 0.105 0.267>
;; RD6006: Tx <values?>
;; RD6006: Tx <holding? 0x08 /100;holding? 0x09 /1000;holding? 0x0A /100;holding? 0x0B /1000;holding? 0x0D /100;holding? 0x21 /100;holding? 0x23;holdingl? 0x26 /1000;holdingl? 0x28 /1000>
;; COM7: Tx: 01 03 00 08 00 01 05 C8
java.lang.NullPointerException
        at dk.hkj.devices.DeviceModbus$TranslatingCommInterface.readHoldingInput(DeviceModbus.java:445)
        at dk.hkj.devices.DeviceModbus$TranslatingCommInterface.write(DeviceModbus.java:268)
        at dk.hkj.comm.CommInterface.writeRead(CommInterface.java:102)
        at dk.hkj.main.SCPICommand.writeReadDelay(SCPICommand.java:146)
        at dk.hkj.main.SCPICommand.writeReadInternal(SCPICommand.java:183)
        at dk.hkj.main.SCPICommand.writeRead(SCPICommand.java:225)
        at dk.hkj.main.SCPICommand.readNumbers(SCPICommand.java:305)
        at dk.hkj.main.DeviceInterface.getValuesFromDevices(DeviceInterface.java:327)
        at dk.hkj.devices.DeviceSCPI.getValuesFromDevices(DeviceSCPI.java:38)
        at dk.hkj.main.InterfaceThreads$DeviceThread.run(InterfaceThreads.java:907)
;; RD6006: Rx Timeout
;; RD6006: Delay: 100ms
;; RD6006: Rx as numbers <NaN>
;; RD6006: Tx <values?>
;; RD6006: Tx <holding? 0x08 /100;holding? 0x09 /1000;holding? 0x0A /100;holding? 0x0B /1000;holding? 0x0D /100;holding? 0x21 /100;holding? 0x23;holdingl? 0x26 /1000;holdingl? 0x28 /1000>
;; COM7: Tx: 01 03 00 08 00 01 05 C8
;; COM7: Rx: 01 03 02 01 4A 38 23
;; COM7: Tx: 01 03 00 09 00 01 54 08
;; COM7: Rx: 01 03 02 00 FA 38 07
;; COM7: Tx: 01 03 00 0A 00 01 A4 08
;; COM7: Rx: 01 03 02 00 FD 79 C5
;; COM7: Tx: 01 03 00 0B 00 01 F5 C8
;; COM7: Rx: 01 03 02 00 FB F9 C7
;; COM7: Tx: 01 03 00 0D 00 01 15 C9
;; COM7: Rx: 01 03 02 00 3F F8 54
;; COM7: Tx: 01 03 00 21 00 01 D4 00
;; COM7: Rx: 01 03 02 00 04 B9 87
;; COM7: Tx: 01 03 00 23 00 01 75 C0
;; COM7: Rx: 01 03 02 00 1E 38 4C
;; COM7: Tx: 01 03 00 26 00 02 25 C0
;; COM7: Rx: 01 03 04 00 00 00 6A 7A 1C
;; COM7: Tx: 01 03 00 28 00 02 44 03
;; COM7: Rx: 01 03 04 00 00 01 0C FB A6
;; RD6006: Rx <3.3000000000000003 0.25 2.5300000000000002 0.251 0.63 0.04 30 0.106 0.268>
;; RD6006: Delay: 100ms
;; RD6006: Rx as numbers <3.3000000000000003 0.25 2.5300000000000002 0.251 0.63 0.04 30.0 0.106 0.268>
;; RD6006: Tx <values?>


[HKJ]

I am mostly finished with the device file for the Riden RD6006. Intermittently I am still getting Rx Timeout at the default baud rate of 115200 (see below). Do you have any suggestions that would help this issue, see attached device file for the current settings

I have uploaded a new .jar file with a answer timeout, this timeout is from the end of transmission until it receives the first byte of the answer. If nothing is received within the timeout it will retransmit the request.

The setting is:
#answerTimeout 20

The value 20 is probably a good value, you will have to check the log, and you have to that at both 115200 and 9600 baud. What you must look for is duplicate "Tx: xx xx xx xx" (i.e. when the same Tx is repeated without any Rx in between). If they occur regulary your timeout is too short.

The main 1 second  message timeout is still active (#readingDelay) and if the communication time is above that the message will fail. That timeout applies to the "values?" command.

When working with timeouts it may be a good idea to change a line in the TextControllerDebug.bat file to:

java -jar TestController.jar debugTime %1 %2 %3 %4 %5 %6 %7 %8 %9

The you will get time stamps on each debug line and can see exactly how fast things are running.

[voltsandjolts]

Thanks for this useful software 
I have attached a settings file for Keithley 2000.

[HKJ]

Thanks for this useful software 
I have attached a settings file for Keithley 2000.

Thanks, it will be included in the next release.
I have add a #author statement with your handle.

[MikeLud]

HKJ,

I tried every combination using #answerTimeout and #cmdDelayTime. Adding #answerTimeout made it worst doing multiple retransmitions.

Below is using #cmdDelayTime 50 #answerTimeout 20- I tried as high as 200 same results for all Tx

Code: [Select]

;; 22:37:34.384 COM5: Set params: 115200
;; 22:37:34.584 : Tx <holdingl? 0x01>
;; 22:37:34.584 COM5: Tx: 01 03 00 01 00 02 95 CB
;; 22:37:34.608 COM5: Tx: 01 03 00 01 00 02 95 CB
;; 22:37:34.631 COM5: Tx: 01 03 00 01 00 02 95 CB
;; 22:37:34.655 COM5: Tx: 01 03 00 01 00 02 95 CB
;; 22:37:34.677 COM5: *** Timeout ***
;; 22:37:34.677 COM5: Rx: 01 03 04 00 00 07 39 38 11
;; 22:37:34.677 : Tx <holding? 0x03 /100>
;; 22:37:34.787 COM5: Tx: 01 03 00 03 00 01 74 0A
;; 22:37:34.810 COM5: Tx: 01 03 00 03 00 01 74 0A
;; 22:37:34.834 COM5: Tx: 01 03 00 03 00 01 74 0A
;; 22:37:34.857 COM5: Tx: 01 03 00 03 00 01 74 0A
;; 22:37:34.879 COM5: *** Timeout ***
;; 22:37:34.949 COM5: Rx: 01 03 02 00 80 B9 E4
;; Found Riden RD6006 on USB2.0-Serial (COM5) sn: 1849
The below is not using any #answerTimeout or #cmdDelayTime, it runs smooth for over 5 minutes and then I get the below.

Code: [Select]

;; 22:57:55.746 RD6006: Tx <values?>
;; 22:57:55.747 RD6006: Tx <holding? 0x08 /100;holding? 0x09 /1000;holding? 0x0A /100;holding? 0x0B /1000;holding? 0x0D /100;holding? 0x21 /100;holding? 0x23;holdingl? 0x26 /1000;holdingl? 0x28 /1000>
;; 22:57:55.748 COM5: Tx: 01 03 00 08 00 01 05 C8
java.lang.NullPointerException
        at dk.hkj.devices.DeviceModbus$TranslatingCommInterface.readHoldingInput(DeviceModbus.java:448)
        at dk.hkj.devices.DeviceModbus$TranslatingCommInterface.write(DeviceModbus.java:271)
        at dk.hkj.comm.CommInterface.writeRead(CommInterface.java:102)
        at dk.hkj.main.SCPICommand.writeReadDelay(SCPICommand.java:146)
        at dk.hkj.main.SCPICommand.writeReadInternal(SCPICommand.java:183)
        at dk.hkj.main.SCPICommand.writeRead(SCPICommand.java:225)
        at dk.hkj.main.SCPICommand.readNumbers(SCPICommand.java:305)
        at dk.hkj.main.DeviceInterface.getValuesFromDevices(DeviceInterface.java:327)
        at dk.hkj.devices.DeviceSCPI.getValuesFromDevices(DeviceSCPI.java:38)
        at dk.hkj.main.InterfaceThreads$DeviceThread.run(InterfaceThreads.java:907)
;; 22:57:56.751 RD6006: Rx Timeout
;; 22:57:56.752 RD6006: Rx as numbers <NaN>
;; 22:57:56.752 RD6006: Tx <values?>

I have uploaded a new .jar file with a answer timeout, this timeout is from the end of transmission until it receives the first byte of the answer. If nothing is received within the timeout it will retransmit the request.

The setting is:
#answerTimeout 20

The value 20 is probably a good value, you will have to check the log, and you have to that at both 115200 and 9600 baud. What you must look for is duplicate "Tx: xx xx xx xx" (i.e. when the same Tx is repeated without any Rx in between). If they occur regulary your timeout is too short.

The main 1 second  message timeout is still active (#readingDelay) and if the communication time is above that the message will fail. That timeout applies to the "values?" command.

When working with timeouts it may be a good idea to change a line in the TextControllerDebug.bat file to:

java -jar TestController.jar debugTime %1 %2 %3 %4 %5 %6 %7 %8 %9

The you will get time stamps on each debug line and can see exactly how fast things are running.

[HKJ]

Please upload a section where everything runs smooth and with any #cmdDelayTime or #answerTimeout, I would like to see the time stamps for that.

[MikeLud]

HKJ,

Good morning, thanks for looking into this. Below is 3 executions of values? #cmdDelayTime and #answerTimeout are not being used. It is almost 1:00 am here in the US, after this post I am gong to get some sleep.

Code: [Select]

;; 00:44:37.128 RD6006: Tx <values?>
;; 00:44:37.128 RD6006: Tx <holding? 0x08 /100;holding? 0x09 /1000;holding? 0x0A /100;holding? 0x0B /1000;holding? 0x0D /100;holding? 0x21 /100;holding? 0x23;holdingl? 0x26 /1000;holdingl? 0x28 /1000>
;; 00:44:37.128 COM7: Tx: 01 03 00 08 00 01 05 C8
;; 00:44:37.159 COM7: Rx: 01 03 02 01 4A 38 23
;; 00:44:37.160 COM7: Tx: 01 03 00 09 00 01 54 08
;; 00:44:37.266 COM7: Rx: 01 03 02 01 F4 B8 53
;; 00:44:37.267 COM7: Tx: 01 03 00 0A 00 01 A4 08
;; 00:44:37.372 COM7: Rx: 01 03 02 01 4A 38 23
;; 00:44:37.373 COM7: Tx: 01 03 00 0B 00 01 F5 C8
;; 00:44:37.478 COM7: Rx: 01 03 02 01 48 B9 E2
;; 00:44:37.479 COM7: Tx: 01 03 00 0D 00 01 15 C9
;; 00:44:37.584 COM7: Rx: 01 03 02 00 6C B8 69
;; 00:44:37.591 COM7: Tx: 01 03 00 21 00 01 D4 00
;; 00:44:37.691 COM7: Rx: 01 03 02 00 06 38 46
;; 00:44:37.698 COM7: Tx: 01 03 00 23 00 01 75 C0
;; 00:44:37.797 COM7: Rx: 01 03 02 00 1D 78 4D
;; 00:44:37.803 COM7: Tx: 01 03 00 26 00 02 25 C0
;; 00:44:37.899 COM7: Rx: 01 03 04 00 00 00 62 7B DA
;; 00:44:37.911 COM7: Tx: 01 03 00 28 00 02 44 03
;; 00:44:38.002 COM7: Rx: 01 03 04 00 00 01 26 7A 79
;; 00:44:38.016 RD6006: Rx <3.3000000000000003 0.5 3.3000000000000003 0.328 1.08 0.06 29 0.098 0.294>
;; 00:44:38.023 RD6006: Rx as numbers <3.3000000000000003 0.5 3.3000000000000003 0.328 1.08 0.06 29.0 0.098 0.294>
;; 00:44:38.141 RD6006: Tx <values?>
;; 00:44:38.142 RD6006: Tx <holding? 0x08 /100;holding? 0x09 /1000;holding? 0x0A /100;holding? 0x0B /1000;holding? 0x0D /100;holding? 0x21 /100;holding? 0x23;holdingl? 0x26 /1000;holdingl? 0x28 /1000>
;; 00:44:38.144 COM7: Tx: 01 03 00 08 00 01 05 C8
;; 00:44:38.219 COM7: Rx: 01 03 02 01 4A 38 23
;; 00:44:38.219 COM7: Tx: 01 03 00 09 00 01 54 08
;; 00:44:38.320 COM7: Rx: 01 03 02 01 F4 B8 53
;; 00:44:38.329 COM7: Tx: 01 03 00 0A 00 01 A4 08
;; 00:44:38.429 COM7: Rx: 01 03 02 01 4A 38 23
;; 00:44:38.429 COM7: Tx: 01 03 00 0B 00 01 F5 C8
;; 00:44:38.540 COM7: Rx: 01 03 02 01 48 B9 E2
;; 00:44:38.540 COM7: Tx: 01 03 00 0D 00 01 15 C9
;; 00:44:38.640 COM7: Rx: 01 03 02 00 6C B8 69
;; 00:44:38.654 COM7: Tx: 01 03 00 21 00 01 D4 00
;; 00:44:38.752 COM7: Rx: 01 03 02 00 07 F9 86
;; 00:44:38.759 COM7: Tx: 01 03 00 23 00 01 75 C0
;; 00:44:38.857 COM7: Rx: 01 03 02 00 1D 78 4D
;; 00:44:38.865 COM7: Tx: 01 03 00 26 00 02 25 C0
;; 00:44:38.965 COM7: Rx: 01 03 04 00 00 00 62 7B DA
;; 00:44:38.971 COM7: Tx: 01 03 00 28 00 02 44 03
;; 00:44:39.069 COM7: Rx: 01 03 04 00 00 01 27 BB B9
;; 00:44:39.078 RD6006: Rx <3.3000000000000003 0.5 3.3000000000000003 0.328 1.08 0.07 29 0.098 0.295>
;; 00:44:39.085 RD6006: Rx as numbers <3.3000000000000003 0.5 3.3000000000000003 0.328 1.08 0.07 29.0 0.098 0.295>
;; 00:44:39.162 RD6006: Tx <values?>
;; 00:44:39.162 RD6006: Tx <holding? 0x08 /100;holding? 0x09 /1000;holding? 0x0A /100;holding? 0x0B /1000;holding? 0x0D /100;holding? 0x21 /100;holding? 0x23;holdingl? 0x26 /1000;holdingl? 0x28 /1000>
;; 00:44:39.162 COM7: Tx: 01 03 00 08 00 01 05 C8
;; 00:44:39.178 COM7: Rx: 01 03 02 01 4A 38 23
;; 00:44:39.178 COM7: Tx: 01 03 00 09 00 01 54 08
;; 00:44:39.283 COM7: Rx: 01 03 02 01 F4 B8 53
;; 00:44:39.283 COM7: Tx: 01 03 00 0A 00 01 A4 08
;; 00:44:39.388 COM7: Rx: 01 03 02 01 4A 38 23
;; 00:44:39.388 COM7: Tx: 01 03 00 0B 00 01 F5 C8
;; 00:44:39.496 COM7: Rx: 01 03 02 01 48 B9 E2
;; 00:44:39.497 COM7: Tx: 01 03 00 0D 00 01 15 C9
;; 00:44:39.600 COM7: Rx: 01 03 02 00 6C B8 69
;; 00:44:39.609 COM7: Tx: 01 03 00 21 00 01 D4 00
;; 00:44:39.701 COM7: Rx: 01 03 02 00 07 F9 86
;; 00:44:39.716 COM7: Tx: 01 03 00 23 00 01 75 C0
;; 00:44:39.811 COM7: Rx: 01 03 02 00 1E 38 4C
;; 00:44:39.823 COM7: Tx: 01 03 00 26 00 02 25 C0
;; 00:44:39.922 COM7: Rx: 01 03 04 00 00 00 62 7B DA
;; 00:44:39.927 COM7: Tx: 01 03 00 28 00 02 44 03
;; 00:44:40.021 COM7: Rx: 01 03 04 00 00 01 27 BB B9
;; 00:44:40.035 RD6006: Rx <3.3000000000000003 0.5 3.3000000000000003 0.328 1.08 0.07 30 0.098 0.295>
;; 00:44:40.042 RD6006: Rx as numbers <3.3000000000000003 0.5 3.3000000000000003 0.328 1.08 0.07 30.0 0.098 0.295>

Please upload a section where everything runs smooth and with any #cmdDelayTime or #answerTimeout, I would like to see the time stamps for that.

[HKJ]

Good morning, thanks for looking into this. Below is 3 executions of values? #cmdDelayTime and #answerTimeout are not being used. It is almost 1:00 am here in the US, after this post I am gong to get some sleep.

What I can see from this is that each transaction takes slightly above 100ms and assuming that you use 115200 baud this means #answerTimeout must be at least 100 to work, maybe 120 to 150 is better.

But is also means you have to either increase #readingDelay or to collect fewer data. The total data collection is is nearly a second. For reliable 1 second logging I would prefer it below 700ms (0.7second). It may still be necessary to increase #readingDelay at that level if the power supply sometimes is slow to answer or a retransmission is needed, but a single slow collection once in a while will not affect logging.

[HKJ]

V0.50 is up.
One new device included: Keithley 2000

Added logging directly to disk (Table will still be updated), this is designed for long logging session and has some side effects:
A memory optimizer is enabled, this will kick in at 30000 records (repeatedly) and throw 2/3 of the data in the table out and reduce the data sample rate for the table. It do not affect the logging to disk. This means it is possible to log for years without running out of memory
When the optimizer has reduced data rate it is not possible to save the table anymore, use the copy that is already being saved to disk.
The disk copy is being completely saved to disk at regular intervals.

I have fixed some bugs and made som improvements on the save dialogs, it is not directly visible.

[MikeLud]

HKJ,

I reduced  the number of data points being collected and are used the below setting. No matter what #answerTimeout setting used every holding command has 4 Tx's before receiving a response. 

V0.50
Logging 1 second
#port comfixedbaud
#baudrate 115200
#cmdDelayTime 50
#answerTimeout 150
#readingDelay 2

Code: [Select]

;; 08:43:38.141 RD6006: Tx <values?>
;; 08:43:38.148 RD6006: Tx <holding? 0x0A /100;holding? 0x0B /1000;holding? 0x0D /100;holding? 0x21 /100;holding? 0x23>
;; 08:43:38.179 COM7: Tx: 01 03 00 0A 00 01 A4 08
;; 08:43:38.333 COM7: Tx: 01 03 00 0A 00 01 A4 08
;; 08:43:38.487 COM7: Tx: 01 03 00 0A 00 01 A4 08
;; 08:43:38.640 COM7: Tx: 01 03 00 0A 00 01 A4 08
;; 08:43:38.795 COM7: *** Timeout ***
;; 08:43:38.795 COM7: Rx: 01 03 02 01 4A 38 23
;; 08:43:38.845 COM7: Tx: 01 03 00 0B 00 01 F5 C8
;; 08:43:38.998 COM7: Tx: 01 03 00 0B 00 01 F5 C8
;; 08:43:39.150 COM7: Tx: 01 03 00 0B 00 01 F5 C8
;; 08:43:39.303 COM7: Tx: 01 03 00 0B 00 01 F5 C8
;; 08:43:39.457 COM7: *** Timeout ***
;; 08:43:39.464 COM7: Rx: 01 03 02 01 48 B9 E2
;; 08:43:39.522 COM7: Tx: 01 03 00 0D 00 01 15 C9
;; 08:43:39.682 COM7: Tx: 01 03 00 0D 00 01 15 C9
;; 08:43:39.842 COM7: Tx: 01 03 00 0D 00 01 15 C9
;; 08:43:40.001 COM7: Tx: 01 03 00 0D 00 01 15 C9
;; 08:43:40.160 COM7: *** Timeout ***
;; 08:43:40.167 COM7: Rx: 01 03 02 00 6C B8 69
;; 08:43:40.225 COM7: Tx: 01 03 00 21 00 01 D4 00
;; 08:43:40.384 COM7: Tx: 01 03 00 21 00 01 D4 00
;; 08:43:40.542 COM7: Tx: 01 03 00 21 00 01 D4 00
;; 08:43:40.703 COM7: Tx: 01 03 00 21 00 01 D4 00
;; 08:43:40.862 COM7: *** Timeout ***
;; 08:43:40.869 COM7: Rx: 01 03 02 00 07 F9 86
;; 08:43:40.926 COM7: Tx: 01 03 00 23 00 01 75 C0
;; 08:43:41.085 COM7: Tx: 01 03 00 23 00 01 75 C0
;; 08:43:41.243 COM7: Tx: 01 03 00 23 00 01 75 C0
;; 08:43:41.402 COM7: Tx: 01 03 00 23 00 01 75 C0
;; 08:43:41.561 COM7: *** Timeout ***
;; 08:43:41.568 COM7: Rx: 01 03 02 00 1B F8 4F
;; 08:43:41.575 RD6006: Rx <3.3000000000000003 0.328 1.08 0.07 27>
;; 08:43:41.582 RD6006: Rx as numbers <3.3000000000000003 0.328 1.08 0.07 27.0>
;; 08:43:41.588 RD6006: Tx <values?>
;; 08:43:41.594 RD6006: Tx <holding? 0x0A /100;holding? 0x0B /1000;holding? 0x0D /100;holding? 0x21 /100;holding? 0x23>
;; 08:43:41.625 COM7: Tx: 01 03 00 0A 00 01 A4 08
;; 08:43:41.778 COM7: Tx: 01 03 00 0A 00 01 A4 08
;; 08:43:41.932 COM7: Tx: 01 03 00 0A 00 01 A4 08
;; 08:43:42.086 COM7: Tx: 01 03 00 0A 00 01 A4 08
;; 08:43:42.241 COM7: *** Timeout ***
;; 08:43:42.241 COM7: Rx: 01 03 02 01 4A 38 23
;; 08:43:42.291 COM7: Tx: 01 03 00 0B 00 01 F5 C8
;; 08:43:42.446 COM7: Tx: 01 03 00 0B 00 01 F5 C8
;; 08:43:42.601 COM7: Tx: 01 03 00 0B 00 01 F5 C8
;; 08:43:42.650 COM7: Rx: 01 03 02 01 48 B9 E2
;; 08:43:42.700 COM7: Tx: 01 03 00 0D 00 01 15 C9
;; 08:43:42.857 COM7: Tx: 01 03 00 0D 00 01 15 C9
;; 08:43:43.015 COM7: Tx: 01 03 00 0D 00 01 15 C9
;; 08:43:43.175 COM7: Tx: 01 03 00 0D 00 01 15 C9
;; 08:43:43.333 COM7: *** Timeout ***
;; 08:43:43.339 COM7: Rx: 01 03 02 00 6C B8 69
;; 08:43:43.396 COM7: Tx: 01 03 00 21 00 01 D4 00
;; 08:43:43.556 COM7: Tx: 01 03 00 21 00 01 D4 00
;; 08:43:43.715 COM7: Tx: 01 03 00 21 00 01 D4 00
;; 08:43:43.873 COM7: Tx: 01 03 00 21 00 01 D4 00
;; 08:43:44.033 COM7: *** Timeout ***
;; 08:43:44.040 COM7: Rx: 01 03 02 00 06 38 46
;; 08:43:44.096 COM7: Tx: 01 03 00 23 00 01 75 C0
;; 08:43:44.255 COM7: Tx: 01 03 00 23 00 01 75 C0
;; 08:43:44.414 COM7: Tx: 01 03 00 23 00 01 75 C0
;; 08:43:44.571 COM7: Tx: 01 03 00 23 00 01 75 C0
;; 08:43:44.730 COM7: *** Timeout ***
;; 08:43:44.737 COM7: Rx: 01 03 02 00 1B F8 4F
;; 08:43:44.743 RD6006: Rx <3.3000000000000003 0.328 1.08 0.06 27>
;; 08:43:44.750 RD6006: Rx as numbers <3.3000000000000003 0.328 1.08 0.06 27.0>

Good morning, thanks for looking into this. Below is 3 executions of values? #cmdDelayTime and #answerTimeout are not being used. It is almost 1:00 am here in the US, after this post I am gong to get some sleep.

What I can see from this is that each transaction takes slightly above 100ms and assuming that you use 115200 baud this means #answerTimeout must be at least 100 to work, maybe 120 to 150 is better.

But is also means you have to either increase #readingDelay or to collect fewer data. The total data collection is is nearly a second. For reliable 1 second logging I would prefer it below 700ms (0.7second). It may still be necessary to increase #readingDelay at that level if the power supply sometimes is slow to answer or a retransmission is needed, but a single slow collection once in a while will not affect logging.

[klausES]

Although it is certainly still being developed, it has now become so good that I use this program almost every day.
I really wanted to thank you for that. 

And also many thanks to MikeLud.
He designed the definition and even the mode windows for the SDM3055 (mode, according to my wishes). 

Together with saving the positions, everything now fits very nicely.

Screenshot example on optics SDM3055 Temp and Volt DC:

[HKJ]

I reduced  the number of data points being collected and are used the below setting. No matter what #answerTimeout setting used every holding command has 4 Tx's before receiving a response. 

It is very strange, with the M9712C I am testing with I can set the #answerTimeout to 13 and I will get occasionally retransmits with a higher value there is no retransmits.
I have uploaded a new jar file (V0.51) where I have switched to another time in java (From currentTimeMillis() to nanoTime()), all settings and other code is exactly the same. I wonder if this will change anything.
Technically there is no guarantee that millis will increase every millisecond, but it is a long time since I have seen it being really slow (Originally it was something like a increased by 55 every 55 millisecond on Windows)

The only problem I see with the M9712C is that I have to unplug/replug the USB interface if I power of the load or I get 100% timeout.

[HKJ]

And also many thanks to MikeLud.

He have done a fine job with the Siglent, but I have only included the 3065x with the full setup. I hope he will say ok for the 3055 soon.
And I wonder if it is possible to duplicate to support modes both with and without x (It only needs are few lines at the top of the file to enable both versions).

[MikeLud]

HKJ,

No matter what I do I can not get it to run 100% timeout free. The best I can get it is maybe 2 to 5 timeout in and hour. The only issue with this is when the timeout happens it records all the data for that time as zero. Maybe a workaround can be to ignore the data if a timeout happens and use ether the previous data or the next valid data without a timeout

Thanks
MikeLud

[MikeLud]

HKJ,

You can use the attached as the final version for the Siglent SDM3055, When I work on updating the SDM3045X file I will look at combining all of the Siglent SDM's into one file. Also I notice that in your download you have two files for the SDM3065X one ending with -4.

 SiglentSDM3055.txt (12.42 kB - downloaded 107 times.)

And also many thanks to MikeLud.

He have done a fine job with the Siglent, but I have only included the 3065x with the full setup. I hope he will say ok for the 3055 soon.
And I wonder if it is possible to duplicate to support modes both with and without x (It only needs are few lines at the top of the file to enable both versions).

[HKJ]

You can use the attached as the final version for the Siglent SDM3055, When I work on updating the SDM3045X file I will look at combining all of the Siglent SDM's into one file. Also I notice that in your download you have two files for the SDM3065X one ending with -4.

Done. It looks like that get adding when I download, I have removed the extra file.