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

[HKJ]

Yes I did find how to change the format but that doesn't help me. I can set the counter to 10 digits and 10 second gate time but TestController changes it to display 9 digits and 1 second gate time and it only returns the 9 digits. The popup has a gate time setting but it doesn't appear to do anything.

I can see everything got resolved, I will just add a comment:

Test controller has a option for sending initial commands to the device, what is sent is up to the author of the driver.
A reasonable initialization may set the measure speed to 1 sec or less, because that works best with TC.

[HKJ]

(..... BTW I like the dummy interface a lot !!)

Just a few comments:
You can use other names for the dummy interface, put the name in the address field. This makes it possible to have multiple devices with dummy interface active simultaneous (I hope, I have not tested it) or to save different configuration for the dummy interface.

I have more plans with the dummy interface, but it is not a high priority to implement them.

One thing I have not decide yet is if I make a option to save a dummy interface as script and recreate it as script, or more simple add a option to save/load it from a user specified file in its native format.

[KungFuJosh]

One thing I have not decide yet is if I make a option to save a dummy interface as script and recreate it as script, or more simple add a option to save/load it from a user specified file in its native format.

If you could make a dummy interface that could be definied in a normal definition file with a special #meta set, that would be pretty awesome.

[HKJ]

One thing I have not decide yet is if I make a option to save a dummy interface as script and recreate it as script, or more simple add a option to save/load it from a user specified file in its native format.

If you could make a dummy interface that could be definied in a normal definition file with a special #meta set, that would be pretty awesome.

Interesting idea, I will think about it.

You can preview Magnavox in the test version, I fixed that.

[Gertjan]

Finally could reproduce the hanging LOG behavior in TC since version >2.77 with help of the Dummy interface.

That lead directly to the error, it was a deadlock (I already expected that, but they can be very hard to locate and fix).
This time it was a easy to locate and fix, because I could reproduce it.

There is a new test version up.

THANK YOU HKJ! I tested with testversion v2.89 and problem is solved .

And thanks to flash2b, for making this problem easy to reproduce with a dummy driver example.

regards, Gertjan.

[Gertjan]

Yes I did find how to change the format but that doesn't help me. I can set the counter to 10 digits and 10 second gate time but TestController changes it to display 9 digits and 1 second gate time and it only returns the 9 digits. The popup has a gate time setting but it doesn't appear to do anything.

I can see everything got resolved, I will just add a comment:

Test controller has a option for sending initial commands to the device, what is sent is up to the author of the driver.
A reasonable initialization may set the measure speed to 1 sec or less, because that works best with TC.

Indeed the Racal-Dana counters are initiated with a gate time of 100ms. This with quick response time in TC in mind.
But users often want more resolution .

regards, Gertjan.

[HKJ]

One thing I have not decide yet is if I make a option to save a dummy interface as script and recreate it as script, or more simple add a option to save/load it from a user specified file in its native format.

If you could make a dummy interface that could be definied in a normal definition file with a special #meta set, that would be pretty awesome.

Interesting idea, I will think about it.

A idea would be to add a #dummyInit tag and the dummy config file can be copied to after that and will be used to initialize a dummy interface if selected and no saved definition or a init button is pressed in the dummy popup.
I believe this would be fairly easy to implement.

[flash2b]

Finally could reproduce the hanging LOG behavior in TC since version >2.77 with help of the Dummy interface.

That lead directly to the error, it was a deadlock (I already expected that, but they can be very hard to locate and fix).
This time it was a easy to locate and fix, because I could reproduce it.

There is a new test version up.

Thank you, HKJ. It works now.

As for  the dummy interface, currently all my command-responses are in the same file and since they are different brand/types there is now interference as such. I agree if a test-set could be a separate item next to the definition, it is very useful as a regression test for both normal behavior as well as error handling while writing/debugging a definition. For people that just use TC with existing definition, it is also useful since it provides a method of interaction with TC and all its glory without having a device attached or learn how things operate or how a definition works. I understand that the last benefit is not for all but it can support such event.

[HKJ]

As for  the dummy interface, currently all my command-responses are in the same file and since they are different brand/types there is now interference as such.

Why don't you use different configuration files for the different devices (Name of config file goes in address field on load devices page)?

[HKJ]

I added a bit to the dummy interface.

#dummyInit can now be added to any definition and the lines following it is the configuration for the dummy interface.
If the port is dummy TC will check the loaded dummy interface and the predefined for *idn? string and if they do not match it will load the dummy interface definition from the driver overwriting any preexisting dummy definition without any warning!

i.e.

#idString brand,device,
#name brand device
#port dummy
#driver SCPI

#dummyInit
cmd:*IDN?|init:|ex:"brand,device,"

Will create a working dummy interface for any device
This can also be used on devices that do not use a *idn? command, the command will be present in the interface, but just never used.
Also be aware that the dummy interface do not look for or use the #idString definition, that is for other parts of TC.

I have added save/load buttons to the dummy interface popup, making it possible to save a definition anywhere with any name and load it later.

It is possible to list multiple types after a port, i.e.
#port com dummy
Is valid and makes it possible for the user to select dummy from the "load devices" page.

[flash2b]

I managed to make a separate dummy config file. The name of the file is settingsDummyYOKO756x.txt and I put YOKO756x in the address field of the load devices page.



Also tested the new #dummyInit with TC v2.90 with embedded config statements. That created a settingsDummyDummy.txt file with the content of the statements. May be I should have used also a new name in the address field for this filename to change. In my case I left the address field empty which defaults to the second Dummy.

All and all I am happy with the result. I am thinking of updating my definitions so they have an embedded dummy config statements where users will be able to run the definition without owning the meter/device. For testing this is also very useful for myself (as explained some posts above).

[HKJ]

Also tested the new #dummyInit with TC v2.90 with embedded config statements. That created a settingsDummyDummy.txt file with the content of the statements. May be I should have used also a new name in the address field for this filename to change. In my case I left the address field empty which defaults to the second Dummy.

Seeing you post I realized that there is a bug in my code: It is only ever supposed to auto create the definition if it contains a *idn? definition and the current dummy definition do not have a matching one.
This will be fixed in next update, so remember to add a (dummy) *idn? to your definition.

The purpose of this is to avoid overwriting the current definition if you make some changes to it (the *idn? is never supposed to change, because it must match the device).

[flash2b]

Why not use the #handle value as the identifier? I have many metadefs and some have an *idn while other models in the same def do not have it.

[HKJ]

Why not use the #handle value as the identifier? I have many metadefs and some have an *idn while other models in the same def do not have it.

The purpose of matching the *idn? is to prevent overwriting any modifications you make to the dummy configuration.
In a file with multiple definitions it is slightly more tricky to setup the dummy init, but not by much (Use a text substitute for the *idn? answer). Defining a *idn? in dummy for a device not using it, is perfectly fine.

Also note that the dummy driver do not have any access to the device definition, it one way: The device can write to dummy, but dummy cannot reach back to get anything.
That also means dummy cannot read the init definition, instead it is transferred to the dummy by the device initialization code that has access to both.

[flash2b]

Dear HKJ,

I have added support of the Prema 4001 and Prema 6000 to my existing definition.

I also added the embedded the new #dummyInit embedded config statements that come with with TC v2.90.

Another 2 models with TC support 

[ Attachment Invalid Or Does Not Exist ]

[HKJ]

Dear HKJ,

I have added support of the Prema 4001 and Prema 6000 to my existing definition.

I also added the embedded the new #dummyInit embedded config statements that come with with TC v2.90.

Another 2 models with TC support 

I have updated the file, thanks.
I can see you are missing the *idn?, you can get away with that on device that do not require startup identification, there you can just use the predefined button to init the dummy driver.
But any device that refuses to load/start without a valid device will not allow you to init the dummy definition.

[flash2b]

What about devices that use #verifyDevice ?

Is something needed for #dummyInit and some lines for embedded config ?

[HKJ]

What about devices that use #verifyDevice ?

You will need a dummy *idn? statement. TC will not load the device or the dummy driver if it do not match a verification, this means you cannot get access to the dummy popup to configure it.

Is something needed for #dummyInit and some lines for embedded config ?

I am not sure what you mean, the load sequence work like this:
Device driver loads
Comm driver loads (These two lines can be swapped in certain conditions).
The loader transfers the #dummyInit data to the dummy driver
The dummy driver initializes itself, including loading the #dummyInit data if conditions matches.
The device driver check the device id, if that fails everything for this device will be terminated (This termination will not happen if no check is performed).

[flash2b]

When changing back address into COM3, the Type column stays Dummy and does not revert back to Serial.

[HKJ]

When changing back address into COM3, the Type column stays dummy.

Click on dummy and select the other interface (You can select between all interfaces specified on the #port line)

[flash2b]

Ok... there is a selection to revert is back.

[KungFuJosh]

Is it possible that TC can remember the devices selected in order on the Chart? For example, I have DAQ6510 and AG34410A logging data. DAQ is selected first and is red/left column (DAQ is the calibrated device that other devices get tested against).

If I stop logging and restart logging, the colors/places of the devices get switched. Then AG34410A is now red/left side of screen instead of the DAQ and I have to manually uncheck and recheck them in order since TC seems to prefer to go in alphabetic order even if it was selected otherwise.

Thanks,
Josh

[HKJ]

Is it possible that TC can remember the devices selected in order on the Chart? For example, I have DAQ6510 and AG34410A logging data. DAQ is selected first and is red/left column (DAQ is the calibrated device that other devices get tested against).

If I stop logging and restart logging, the colors/places of the devices get switched. Then AG34410A is now red/left side of screen instead of the DAQ and I have to manually uncheck and recheck them in order since TC seems to prefer to go in alphabetic order even if it was selected otherwise.

You can do it with script and TC can generate the script for you, you just need to save it as a menu.
Script can also be assigned to buttons in Grid panel, there are panels for that.

[KungFuJosh]

You can do it with script and TC can generate the script for you, you just need to save it as a menu.
Script can also be assigned to buttons in Grid panel, there are panels for that.

Do you mean Layout or Mode & Setup? Because neither of them do that. Which script are you referring to?

All I really want to do is clear/restart the Chart log without the meter positions changing.

Thanks,
Josh

[HKJ]

Do you mean Layout or Mode & Setup? Because neither of them do that. Which script are you referring to?

All I really want to do is clear/restart the Chart log without the meter positions changing.

The actual script command is #ChartCurves
You can generate it with right clicking on the log window and select "Generate script, Chart/hist/range script"
You can stick #log 0 and #log 1 in before the generated command to restart the log.