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

[HKJ]

Something I see in a number of scripts (genericized here):

="STARTING PARAMETERS "
="Start Voltage = "+startVoltage+" Volt"
="Discharge Current = "+drainCurrentAmps+" Amps"

AFAIK in general, one way to emit a status/error message to the console/log is:
="message"

I attempted to combine that with the triple-quote long-string capability, in a script file...
="""
This is
a long
message
"""

But that fails with an exception. Clearly the contents of the string are being parsed. (my long string contained
     (default: 0.5Ah)
which generated an exception.

Is it possible to do a long-string message?

No, = and # are single line commands (#calc excluded when used outside the command line)
Triple quotes do not work together with # commands, the simple parser that looks for expressions cannot handle it.

SOLUTION AND DIAGNOSIS: From commands tab:
=""foo"" -> comment to log
="""foo""" --> sends to device
#calc """foo""" -> comment to log

so, """long string""" is ONLY for #calc mode?

Basically, it can also be used inside programs stored in their own files.
When doing definitions it can also be used, with a few caveat's

What it will not do is stretch single line stuff to multiple lines.

[MrPete]

@HKJ this appears to be a bug...
this simple script fails, saing #haslogged only works if logging is active -- but I just turned logging on!

Code: [Select]

#log 0
#calc

runScript("""
#log 0.1
#HasLogged
""");

#log 0

If I insert some extra stuff before the #log 0.1, it works. these two lines fix it. does the parser require a plain "#" first?

I'm also discovering runScript() inside a #calc seems to run a separate thread, so I need to use globalvar's instead of vars...

Code: [Select]

#
="a message"


[HKJ]

@HKJ this appears to be a bug...
this simple script fails, saing #haslogged only works if logging is active -- but I just turned logging on!

Code: [Select]

#log 0
#calc

runScript("""
#log 0.1
#HasLogged
""");

#log 0

If I insert some extra stuff before the #log 0.1, it works. these two lines fix it. does the parser require a plain "#" first?

Log is asynchronous, i.e. the start is posted to another thread and it can be a fraction of second before it is processed.
Because the script language can run asynchronous to everything else in TC a lot of stuff runs through a synchronization to do a specific function. Sometimes the script is paused at other times it is not.

I'm also discovering runScript() inside a #calc seems to run a separate thread, so I need to use globalvar's instead of vars...

Code: [Select]

#
="a message"


Both programs and scripts run in separate context and often separate threads.
Separate context will often transfer variables from the caller to the routine, but the routine can only create variables local to itself. A getVarList(2) will show these variables if they exist (Depending on calling depth, it might not be 2, but 3, 4, 5, etc.).
A context keeps track of position inside a program and a lot of other stuff, i.e. any time you run another script/program a new context is needed to keep track of the position.

[HKJ]

Let me elaborate a bit more on this:

A script instance is generally married to a programming language instance and they share variables.
The programming language do not need a script instance and can run on its own, i.e. if a programming language is launched, it will not include a script context.
If a script is launched it will include both a script and a programming language.

The programming language with a script is used for parameters, = and #calc, not for function calls to start a new programming language.

[MrPete]

@HKJ this appears to be a bug...
this simple script fails, saying #haslogged only works if logging is active -- but I just turned logging on!

Code: [Select]

#log 0
#calc

runScript("""
#log 0.1
#HasLogged
""");

#log 0

If I insert some extra stuff before the #log 0.1, it works. these two lines fix it. does the parser require a plain "#" first?

Log is asynchronous, i.e. the start is posted to another thread and it can be a fraction of second before it is processed.
Because the script language can run asynchronous to everything else in TC a lot of stuff runs through a synchronization to do a specific function. Sometimes the script is paused at other times it is not.

So, is there a reliable way in this situation to ensure the log is running?

I would have thought #haslogged would accomplish that.

[HKJ]

So, is there a reliable way in this situation to ensure the log is running?

I would have thought #haslogged would accomplish that.

Do a short delay.

[MrPete]

@HKJ,

With some extensive testing, I'm convinced this isn't a logging issue at all. (The log actually is NOT running! Nothing collected... )

Sure appears to be a bug. Here is a very simple script that fails. No matter what I have tried so far (many variants, including first command on the  runScript(""" line, a plain "#", etc etc... I get three results every time:
* a message that #calc failed, "due to Expect a )"
* the first command in the runScript string is never executed or seen
* there's an "Invalid device <>" error.

Script:

Code: [Select]

#calc
runScript("""
#echo 1234567
#echo 7654321
""");
#
Result:

Code: [Select]

#calc
;; #calc failed due to Expect a )

runScript("""
____<----____
#echo 7654321
;; 7654321
;; Invalid device <>
#

[HKJ]

@HKJ,

With some extensive testing, I'm convinced this isn't a logging issue at all. (The log actually is NOT running! Nothing collected... )

Sure appears to be a bug. Here is a very simple script that fails. No matter what I have tried so far (many variants, including first command on the  runScript(""" line, a plain "#", etc etc... I get three results every time:
* a message that #calc failed, "due to Expect a )"
* the first command in the runScript string is never executed or seen
* there's an "Invalid device <>" error.

Script:

Code: [Select]

#calc
runScript("""
#echo 1234567
#echo 7654321
""");
#
Result:

Code: [Select]

#calc
;; #calc failed due to Expect a )

runScript("""
____<----____
#echo 7654321
;; 7654321
;; Invalid device <>
#

Any line starting with # ends #calc mode, i.e. it ends with the "#echo 1234567"
The trick is to code # as \x23, the line parser will not see that as a #, put the string parser will turn it into a # inside the string.

[MrPete]

Any line starting with # ends #calc mode, i.e. it ends with the "#echo 1234567"
The trick is to code # as \x23, the line parser will not see that as a #, put the string parser will turn it into a # inside the string.

Here's the result:

Code: [Select]

#calc
java.nio.file.InvalidPathException: Illegal char <
> at index 10: c:\tcdata\
#echo 1234567
#echo 7654321.txt
        at sun.nio.fs.WindowsPathParser.normalize(Unknown Source)
        at sun.nio.fs.WindowsPathParser.parse(Unknown Source)
        at sun.nio.fs.WindowsPathParser.parse(Unknown Source)
        at sun.nio.fs.WindowsPath.parse(Unknown Source)
        at sun.nio.fs.WindowsFileSystem.getPath(Unknown Source)
        at java.nio.file.Paths.get(Unknown Source)
        at dk.hkj.main.Support.fileWithOptinalDefaults(Support.java:1645)
        at dk.hkj.main.CommandProcessor.loadScript(CommandProcessor.java:197)
        at dk.hkj.main.CommandProcessor.access$1(CommandProcessor.java:190)
        at dk.hkj.main.CommandProcessor$1.execute(CommandProcessor.java:85)
        at dk.hkj.script.Script.parseValue(Script.java:279)
        at dk.hkj.script.Script.parseBitOp(Script.java:326)
        at dk.hkj.script.Script.parseProduct(Script.java:398)
        at dk.hkj.script.Script.parseSum(Script.java:480)
        at dk.hkj.script.Script.parseCompare(Script.java:535)
        at dk.hkj.script.Script.parseLogical(Script.java:571)
        at dk.hkj.script.Script.parseQuestionMark(Script.java:597)
        at dk.hkj.script.Script.parseExpression(Script.java:622)
        at dk.hkj.script.Script.statement(Script.java:1110)
        at dk.hkj.script.Script.doExecute(Script.java:1261)
        at dk.hkj.script.Script.execute(Script.java:1283)
        at dk.hkj.script.Script.execute(Script.java:1289)
        at dk.hkj.main.CommandProcessor.sysCmdCalc(CommandProcessor.java:2451)
        at dk.hkj.main.CommandProcessor.processCommands(CommandProcessor.java:3011)
        at dk.hkj.main.CommandProcessor$CmdEnvironment.run(CommandProcessor.java:369)
        at dk.hkj.main.CommandProcessor$BackgroundCommands.run(CommandProcessor.java:1789)
;; #calc failed due to Illegal char <
> at index 10: c:\tcdata\
#echo 1234567
#echo 7654321.txt

runScript("""
\x23echo 1234567
\x23echo 7654321""");____<----____


[HKJ]

Here's the result:

This one works:

Code: [Select]

#calc
runScript("""#
\x23echo 1234567
\x23echo 7654321
""")
#

The issue is that runScript do not like a empty line at the start. Because it is not at the start of the line I can directly use # and do not need \x23

# is a valid command and is basically a command and means do nothing.

[MrPete]

This one works:

Code: [Select]

#calc
runScript("""#
\x23echo 1234567
\x23echo 7654321
""")
#

The issue is that runScript do not like a empty line at the start. Because it is not at the start of the line I can directly use # and do not need \x23

# is a valid command and is basically a command and means do nothing.

OK, I can do that. That's more than a little subtle of course. We are defining a complex set of workarounds at this point.

It would be a LOT more flexible and simpler, if at an appropriate point in the stream:
1) any blanks ( [\t ] ) were trimmed out of the start of each line.
- Makes it easy to format things nicely such as with #if/#else/#endif
   #if ....
       #do this
       =....
    #endif
- Eliminates the need for \x23

2) Allow blank lines anywhere in scripts including runScript()
- Again, much nicer for formatting
- Much less picky for coding
- Avoids rather confusing error messages and exceptions

[HKJ]

OK, I can do that. That's more than a little subtle of course. We are defining a complex set of workarounds at this point.

There is a very specific reason why it need that # at the start.
I do explain it in the documentation: https://lygte-info.dk/project/TestControllerFunctions%20UK.html#runScript_&_runScriptAsync

It would be a LOT more flexible and simpler, if at an appropriate point in the stream:
1) any blanks ( [\t ] ) were trimmed out of the start of each line.
- Makes it easy to format things nicely such as with #if/#else/#endif
   #if ....
       #do this
       =....
    #endif
- Eliminates the need for \x23

Trimming blank would not help, they are generally trimmed before processing.
When the script parser do is collect line from #calc until the next # in one block and then send that block to the programming language (One the command line it is done line by line).

2) Allow blank lines anywhere in scripts including runScript()
- Again, much nicer for formatting
- Much less picky for coding
- Avoids rather confusing error messages and exceptions

Generally blank lines are allowed, but you hit a very special situation.
Error messages are often a problem, what the parser see as a problem, is not necessary the original program.

[flash2b]

Dear HKJ,

I have created a new definition for the Dual channel ComWinTop BSR-DA02B Voltage+Voltage and BSR-AA02B Current+Current source modules.

These are very simple compared to the Elecdemo YK-AO23xxx source modules, and have also no software calibration. They rely on screwdriver calibration on the unit 

Well they can be controlled with TestController now.

Please add them to the next release of TestController.

[ Attachment Invalid Or Does Not Exist ]

Part of TestController V3.34

[HKJ]

I have created a new definition for the Dual channel ComWinTop BSR-DA02B Voltage+Voltage and BSR-AA02B Current+Current source modules.

I have added them, thanks.

[MrPete]

OK, I can do that. That's more than a little subtle of course. We are defining a complex set of workarounds at this point.

There is a very specific reason why it need that # at the start.
I do explain it in the documentation: https://lygte-info.dk/project/TestControllerFunctions%20UK.html#runScript_&_runScriptAsyncal

Tweaked spec could be:
The name is trimmed for any blanks before/after. Then, if the name starts with # it is assumed to be the script.

Trimming blank would not help, they are generally trimmed before processing.
When the script parser do is collect line from #calc until the next # in one block and then send that block to the programming language (One the c command line it is done line by line).

If I understand correctly, in this case we have a script file, in #calc, so:
* the script parser is collecting lines after the #calc, searching for a "#" at the beginning of a line
* it will then send all of those lines as a block to the programming language.

That's both understandable and unfortunate
* Understandable: easy for the parser, since obviously a #xxx command must be for a script, not programming.
* Unfortunate: because a program can itself call a script using runScript(), and that script by definition can contain #xxx commands
* Clearly this wasn't a necessary design decision. Almost anything could have been chosen as the termination marker for #calc.

I have yet another suggestion worth about as much as you paid for it LOL. Obviously, this is your design; I'm just a user, and only for a year or so on this system ...  Suggestion: for more comprehensive  programs, a more stable start/end marker pair would be much simpler to code for, such as

#calcblock
(program)
#endcalcblock

Error messages are often a problem, what the parser see as a problem, is not necessary the original program.

YES they are

I have now (mostly?) debugged my 600+ line analyzer program. It's been quite the adventure decoding the error messages. I can say I am now far more familiar with the interesting error messages associated with various typos etc. Rarely do they have much to say directly about the problem. LOL.

In general, any typo or error in a program (vs script) produces a message saying #calc terminated, usually due to "Value". And that's the only hint. (For others attempting to program: adding LOTS of debug messages can help quite a bit; even so, the actual error may be several lines away from where you believe it is. )

[MrPete]

Silly (?) question: how do I set the display units for #popupnumber?

When showing/entering a normally decimal number such as 0.25 Ah, it eventually is wearying to see 250m instead of 0.25

[HKJ]

If I understand correctly, in this case we have a script file, in #calc, so:
* the script parser is collecting lines after the #calc, searching for a "#" at the beginning of a line
* it will then send all of those lines as a block to the programming language.

That's both understandable and unfortunate
* Understandable: easy for the parser, since obviously a #xxx command must be for a script, not programming.
* Unfortunate: because a program can itself call a script using runScript(), and that script by definition can contain #xxx commands
* Clearly this wasn't a necessary design decision. Almost anything could have been chosen as the termination marker for #calc.

runScript() do not only direct script, but was designed to run external files or named scripts loaded by TC (I.e. like a library)
You can also do runScript("#echo 1234567\n#echo 7654321");
Only in the case where you use a multiline staring with # command, will there be issues and it is possible to get around them.

I have yet another suggestion worth about as much as you paid for it LOL. Obviously, this is your design; I'm just a user, and only for a year or so on this system ...  Suggestion: for more comprehensive  programs, a more stable start/end marker pair would be much simpler to code for, such as

#calcblock
(program)
#endcalcblock

I like you suggestion, from next version of TC there will be:
#calcStart
#calcEnd
In addition to the regular #calc
Making this valid:

Code: [Select]

#calcStart
runScript("""#
#echo 1234567
#echo 7654321
""");
#calcEnd

I have now (mostly?) debugged my 600+ line analyzer program. It's been quite the adventure decoding the error messages. I can say I am now far more familiar with the interesting error messages associated with various typos etc. Rarely do they have much to say directly about the problem. LOL.

In general, any typo or error in a program (vs script) produces a message saying #calc terminated, usually due to "Value". And that's the only hint. (For others attempting to program: adding LOTS of debug messages can help quite a bit; even so, the actual error may be several lines away from where you believe it is. )

I have modified the error output from the script parser slightly, now it will also say the name of the exception, this can in a few instances make it easier to guess what went wrong.

[HKJ]

Silly (?) question: how do I set the display units for #popupnumber?

When showing/entering a normally decimal number such as 0.25 Ah, it eventually is wearying to see 250m instead of 0.25

You can't, it is fixed

[flash2b]

The #cmdSetup numberDual suffers from the same bug you fixed that was with #cmdSetup infoAsk.

You cannot use :enable: on #cmdSetup numberDual it will always be on.

Could you fix this ?

[HKJ]

The #cmdSetup numberDual suffers from the same bug you fixed that was with #cmdSetup infoAsk.

You cannot use :enable: on #cmdSetup numberDual it will always be on.

Could you fix this ?

It is fixed.
I did never add it to the control, there are probably a few other controls with the same issue.

[flash2b]

You fixed it! Thanks !

[flash2b]

Still a minor problem. The editable fields do not have a white background. Re-enabling on/of fill make them white but not after the first render of the menu,




The two controls are numberDual the other are advNumber and they work just fine.

[HKJ]

Still a minor problem. The editable fields do not have a white background. Re-enabling on/of fill make them white but not after the first render of the menu,

The two controls are numberDual the other are number and they work just fine.

I have fixed it, but you do not get a new version just yet.

[flash2b]

fine... it is not a big problem.

[MrPete]

I like you suggestion, from next version of TC there will be:
#calcStart
#calcEnd
In addition to the regular #calc
Making this valid:

Code: [Select]

#calcStart
runScript("""#
#echo 1234567
#echo 7654321
""");
#calcEnd...
I have modified the error output from the script parser slightly, now it will also say the name of the exception, this can in a few instances make it easier to guess what went wrong.

AWESOME!!! That will GREATLY help! I suspect it will help resolve/avoid other issues. I've got another one blocking me right now. Will separately post.