Program that can log/control many multimeters and other devices.

[HKJ]

Well... that is very disappointing. Since it worked in v2.77 and now I feel it is my fault that is doesn't anymore.......

It is, I would very much like to find the bug and fix it, but I mostly need to reproduce it here to do that.
That is why it would be very useful if you could reproduce the problem with the dummy driver. Then you can send the dummy definition to me and I can hopefully reproduce the bug.

[flash2b]

Retested Gertjan K199 definition (ascii), that worked.

Retested my Analogic DP100 definition (SCPIx), that worked also.

I see there, what I said before, that logging starts after all scpiCmds of the setup dialog have been retreived. After that, the log button becomes red with label stop log and logging starts.

What do I need to add to the dummy driver dig into this? What do I need to edit, the driver or the config file ?

Both the Hameg and Yokogawa definition just do 1 call to askMode and this sets all the variables that have corresponding scpiCmds for populating the setup menu. This is to prevent communication to the device repeatedly.

The response for the Hameg is just one line, while the Yokogawa has 10 lines.

Both do not support *idn?

[HKJ]

What do I need to add to the dummy driver dig into this? What do I need to edit, the driver or the config file ?

You put dummy in as #port in your definition.
The you open the dummy interface and add commands with plausible answers, view the log on the dummy interface to see what commands are received.
Commands that do not expect a answer, do not need to be included, but by including them you can see what parameters they had (It is stored in the var associated with the command and can be viewed by holding the mouse over the command).

[flash2b]

Hmmmm

#scpiCmd askMode? txrx? L1

L1 is answered with +02.50044E+0VDR3A0T3S0Q0MO by the meter.

For the Hameg HM8112 that is the only command it needs to get all the settings and values.

So where do I configure the dummy driver to respond to the L1 command ? and how ?

[HKJ]

Hmmmm

#scpiCmd askMode? txrx? L1

L1 is answered with +02.50044E+0VDR3A0T3S0Q0MO by the meter.

For the Hameg HM8112 that is the only command it needs to get all the settings and values.

So where do I configure the dummy driver to respond to the L1 command ? and how ?

You open the dummy interface and add the L1 command and the answer.

I have started on the documentation here: https://lygte-info.dk/project/TestControllerDummy%20UK.html

[flash2b]

This is my dummy, not the same !

Is this it ?

[HKJ]

This is my dummy, not the same !

That is just a dummy device and its only relation to the dummy interface is that it uses it.
Check the link I posted above.

[flash2b]

Ok... L1 command in there (without txrx?) and response is added, and the Setup menu loads !! (without the meter !!)

But no Current Values and Logging also works, but no values there as well.

Disabled the other dummy definition, and now it works. Logging and Current Values everytime the same values as from the dummy interface.

But that does not help my initial problem.......

[HKJ]

Ok... L1 command in there (without txrx?) and response is added, and the Setup menu loads !! (without the meter !!)

But no Current Values and Logging also works, but no values there as well.

A number in the for 1E3xxx is not a number, and a space after the number or you need something in your driver to do it.

[flash2b]

It works, but how does it help me when it does not work with the real meter

[HKJ]

It works, but how does it help me when it does not work with the real meter

It makes me wonder if you hit the snag with jSerialComm, some people has seen a issue where it deploys the wrong driver for win64.
I will update it when I see a new version.

[flash2b]

Well the jSerialComm version did not change from v2.77 to v2.84/5.

Also Gertjan K199 definition worked ok and that is the definition I used as basis for my work.

The Hameg HM8112 (is much simpler as the Yokogawa 7551-7552), and uses only 1 command (L1) to read everything from the meter. Maybe you spot the problem when analyzing it.

[HKJ]

Well the jSerialComm version did not change from v2.77 to v2.84/5.

Also GertJan K199 definition worked ok and that is the definition I used as basis for my work.

The Hameg HM8112 (is much simpler as the Yokogawa 7551-7552), and uses only 1 command (L1) to read everything from the meter. Maybe you spot the problem when analyzing it.

Try something else that uses serial and see if it works.
I have no idea when jSerialComm deploys its driver or when it used a previous deployed driver. I uses Win64 and have not seen the problem.

[flash2b]

The K199 uses GPIB using AR488 over a serial connection, the Hameg HM8112 uses exactly the same setup.

The Yokogawa uses RS232 directly.

[HKJ]

The K199 uses GPIB using AR488 over a serial connection, the Hameg HM8112 uses exactly the same setup.

The Yokogawa uses RS232 directly.

They will all be affected if the issues is jSerialComm

[HKJ]

This file is a possible solution to the jSerialComm issue:

http://lygte-info.dk/pic/Projects/TestController/TestControllerjComm2.10.3.jar

It is the newest TC, but with a old serial library. It do not matter for TC, but it may not run on some new computers.

I do not know if jSerialComm will update a wrongly installed driver or still try to use it.

[flash2b]

I retested it with that version, but does not help. 

I removed all #cmdSetup from the Hameg definition. Then it was an empty menu, but no logging issues.

I put some back:
#cmdSetup radio Integration_Time
#cmdSetup buttons Zero_(Offset)

Still ok, no logging issues

But if I put back some more:
#cmdSetup info Active_Mode
#cmdSetup radio Auto_Range
#cmdSetup radio Range VDC (multiple....)

#cmdSetup selector Mode_settings

Then the problem occurred again, no logging.
 Thes
MAJOR breakthrough

I deleted all :updatemodechange: and now logging works again !, but of-course now there are other issues since the menu is not synchronized anymore.

Logging now also starts instantly after pressing the log, the button is red and logging starts without any delay.

------

If I put back :updatemodechange: to #cmdSetup info or #cmdSetup selector then logging does not work anymore !!! These both invoke askMode !!!

[KungFuJosh]

If the syntax is wrong, or missing info, then any cmdSetup entry can break the driver.

[flash2b]

KungFuJosh my definition worked fine with v2.77, so that is not the problem.

It is just that the :updatemodechange: killing the definition since v2.84/5

[KungFuJosh]

I'll only leave this up temporarily, but here's version 2.81 for you to try it with: link removed

[flash2b]

Thank you, I retested it with v2.81 and same issue as with v2.84/5.

So between 2.77 and 2.81 something changed with the handling of :updatemodechange: that affected the logging.

Would it not be easier to have a full refresh of the setup menu after a mode change. If I reopen the setup menu after a mode change everything is all right since all parameters are fetched fresh. Then you also do not have to identify with cmdSetup need a refresh and which don't. My setup menu loads fast since it minimizes communication to the meter.

[HKJ]

Would it not be easier to have a full refresh of the setup menu after a mode change. If I reopen the setup menu after a mode change everything is all right since all parameters are fetched fresh. Then you also do not have to identify with cmdSetup need a refresh and which don't. My setup menu loads fast since it minimizes communication to the meter.

It would be rather bad, when it takes a long time to reload all data.
TC do have a option to refresh all setup windows, but it is for the command line.

Maybe a device depend option to do a full refresh on mode change would be a good idea.

[flash2b]

Yes I would really like that. 

Then the definition-author can choose what is the best option for a redraw.

[KungFuJosh]

TC do have a option to refresh all setup windows, but it is for the command line.

It works in cmdSetup also.

Code: [Select]

#cmdSetup separator - Misc
1 100 Sunken
#scpiCmd SyncPops #pgm#
runScript("#syncPopups");

[HKJ]

It works in cmdSetup also.

Code: [Select]

#cmdSetup separator - Misc
1 100 Sunken
#scpiCmd SyncPops #pgm#
runScript("#syncPopups");

I know and that is nasty coding, a device is not supposed to do stuff to other devices popups!