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

[HKJ]

I recently needed an ac powered meter to do some logging with and thought the Owon XDM1041 would be the cheapest option.  However, on Amazon I saw the same meter with the generic Digcreat name on it for $20 cheaper.  As it turns out it is just a rebrand and otherwise identical to the Owon original.

I edited the existing OwonXDM1041.txt device file with #metadef to add this rebrand since it returns Digcreat,XDM1041 instead of Owon,XDB1041 in response to *IDN?  Attached is the updated device file for others that might run across this rebranded version.

Added, thanks.

You removed the original, but I have restored it!

[flash2b]

#cleartable throws a NullPointerException when the table has Math columns and chart curves configured.

Steps:
1. Log a device so the table has data
2. Create Math entries and set chart curves (in my case from an Other menu:
   #Math AVGCH1..7 Average over the device columns, then #ChartCurves and
   #ChartColors)
3. Type #cleartable

It does not fail on an empty table, and it does not fail on a plain log without the Math entries and curves.

java.lang.NullPointerException
        at dk.hkj.main.PaneHistogram.getEmptyChart(PaneHistogram.java:331)
        at dk.hkj.main.PaneHistogram.updateData(PaneHistogram.java:681)
        at dk.hkj.main.PaneHistogram.access$4(PaneHistogram.java:665)
        at dk.hkj.main.PaneHistogram$1.actionPerformed(PaneHistogram.java:660)
        at dk.hkj.main.PaneHistogram.addCheckboxes(PaneHistogram.java:595)
        at dk.hkj.main.PaneHistogram.changeDevicesOrTable(PaneHistogram.java:697)
        at dk.hkj.main.Main.notifyChangeDevicesOrTableSync(Main.java:178)
        at dk.hkj.main.Main.notifyChangeDevicesOrTable(Main.java:163)
        at dk.hkj.main.Main.changeDevicesOrTable(Main.java:475)
        at dk.hkj.main.CommandProcessor.clearTable(CommandProcessor.java:2463)
        at dk.hkj.main.CommandProcessor.sysCmdClearTable(CommandProcessor.java:2471)
        at dk.hkj.main.CommandProcessor.processCommands(CommandProcessor.java:3075)

It looks like addCheckboxes fires a checkbox action listener while rebuilding, and updateData then asks for a chart from the table that has just been emptied.

[HKJ]

#cleartable throws a NullPointerException when the table has Math columns and chart curves configured.

I will take a look at it tomorrow and thanks for the trace, it will probably make it easy to find.

[HKJ]

#cleartable throws a NullPointerException when the table has Math columns and chart curves configured.

Steps:
1. Log a device so the table has data
2. Create Math entries and set chart curves (in my case from an Other menu:
   #Math AVGCH1..7 Average over the device columns, then #ChartCurves and
   #ChartColors)
3. Type #cleartable

It does not fail on an empty table, and it does not fail on a plain log without the Math entries and curves.

java.lang.NullPointerException
        at dk.hkj.main.PaneHistogram.getEmptyChart(PaneHistogram.java:331)
        at dk.hkj.main.PaneHistogram.updateData(PaneHistogram.java:681)

Found and fixed it, it has nothing to do with #cleartable, but is only related to user defined chart colors.
Basically I did:

if (color!=null)
  chart.setcolor(color1)

It was not that obvious, but nearly.

[flash2b]

Channel colors across the definitions
Something I have been rolling out through my definition files: a single standard color palette, applied the same way everywhere.

The idea is that a channel keeps its color no matter which device you are looking at. Channel 1 is always the same yellow, channel 2 the same cyan, and so on through eight colors:

Code: [Select]

(255,220,0) (0,255,255) (255,0,255) (0,160,255)
(255,165,0) (60,210,90) (190,140,255) (255,120,120)
The channel buttons carry the same colors as the curves. Every toggle button in the bottom bar gets its channel's color through :color:, so the button you press and the curve it produces are visibly the same channel. Nothing has to be looked up.
On a multi-channel module that is the difference between reading a chart and guessing at it — with 8, 20 or 32 channels the legend stops helping and the color has to carry the identity.
For the wider modules the palette repeats per block of eight, and the Other menu gets Show Channels 1-8, 9-16 and so on. Each entry sets the curves, the scales and the colors together, so one click gives you a readable chart instead of eight fields to fill in.
Each definition has three entries in its Other menu:

• Apply Channel Colors Normal — light background
• Apply Channel Colors Dark — same curves, #ChartBackground switched over
• Reset Chart Colors to Default

The reason for a custom palette at all is the dark theme. The default color scheme is fine on white but not well suited to a dark background — several of its colors go muddy or disappear against it. So rather than maintain two palettes, I picked one set of colors bright enough to hold up on both, and the Dark entry only changes the background and the text. Same curves, same colors, both themes comparable side by side.

All of this is documented in the definition files themselves. The version history line records when the Other menu and the standard palette were added, so anyone reading the file can see which release it came in and what changed — no separate notes to go looking for.

The consequence is that I had to build it into every definition I maintain. Each one carries its own copy of the palette, the curve list, the scales and the two theme entries, and any change to the palette means editing all of them again.

It would be worth considering whether TestController itself could hold a few named palettes, with the theme handled at application level. A definition would then say which curves belong to which channels and leave the colors alone, and users who prefer different colors — or who need them for accessibility reasons — could pick a palette without anyone editing a definition file. As it stands, the only place to put this is in the defs, which means it only exists for the devices whose author happened to do the work.

[HKJ]

Channel colors across the definitions
Something I have been rolling out through my definition files: a single standard color palette, applied the same way everywhere.

As long as you keep it in the Other menu, it is fine, but do not build it into the core definition.

[flash2b]

Well it is. However I cannot change the :color: for #cmdSetup which live in the core. Dynamic colors would be a solution instead or pre defined ones.

[KungFuJosh]

I would love it if TC had the color palette options built in. Having a dark palette option is essential for light-sensitivity issues.

Thanks,
Josh

[HKJ]

I generally prefer menu colors are static.

A dark theme would be nice, but it is way to much work to do and there is also the issue that Java do not really allow you to change button colors (They render flat if you do).

[flash2b]

Fair enough on both counts, and the flat button rendering is a real Java limitation — I have run into that one myself.

Worth adding why I put this in the Other menu at all, because it is not really about the colors.

In the chart the color follows the order the curves were added. Add them by hand and the colors depend on the order you happened to click, which is different the next time you set it up. Channel 3 is magenta today and cyan tomorrow.

The Other menu entry sets the curves, the scales, the scale sync and the colors together, in a fixed order. That is what makes it repeatable — the palette is only the visible part of it. Far less clicking, and always the same result.

That matters most in repetitive testing. Every reboot or restart means setting the whole chart up again by hand, and with eight channels that is a lot of fields to fill in before you can even start measuring. In my definitions that step is gone — one menu entry and the chart is exactly as it was.

Which also means a static default palette does not give consistency on its own, since the ordering is what assigns the colors. Keeping it in the definition is fine by me — it is my definition and my preference.

[flash2b]

This is how it is combined in one of my unreleased def's

[HKJ]

This is how it is combined in one of my unreleased def's

It looks nice, but how do it play together with other loaded devices?

[flash2b]

All my defs have the same other menu (sometimes including combined y axis for Averaging and uncombine).

They will disable the chart curves of the others while enabling from the calling def.

This saves me so much time.

As you can see I can switch Normal, Dark and default TC style. This last one will make it native TC again.

[KungFuJosh]

I wasn't thinking about the whole program. Having default themes available specifically for the chart would be nice.

That said, flat buttons aren't a terrible thing.

[HKJ]

As you can see I can switch Normal, Dark and default TC style. This last one will make it native TC again.

I do not really like you call it normal, light or something else would be better, normal make it sound like TC's normal colors.

I wasn't thinking about the whole program. Having default themes available specifically for the chart would be nice.

That could happen as a selection in the Layout/color menu. Got any good sets I can use (Thats also includes Flash2b and other people)? Post them as script commands, then it is easy to test them.

That said, flat buttons aren't a terrible thing.

They are, a colored rectangle do not say it is a button.

[flash2b]

I can rename to Light, it is linked to the background color which is Normal = Default.

[flash2b]

Dark

Code: [Select]

#delay 0
#ChartColors (255,220,0) (0,255,255) (255,0,255) (0,160,255) (255,165,0) (60,210,90) (190,140,255) (255,120,120)
#ChartBackground black black (80,80,80) white - (180,180,180)
Normal/Light

Code: [Select]

#delay 0
#ChartReset
#ChartColors (255,220,0) (0,255,255) (255,0,255) (0,160,255) (255,165,0) (60,210,90) (190,140,255) (255,120,120)
But my script is more than that since it set Scales, Math, ChartScaleSync and all the resets.

[HKJ]

I can rename to Light, it is linked to the background color which is Normal = Default.

I assume you override some other colors.
If it is just setting up the traces another name would probably be better.

[HKJ]

Dark

Code: [Select]

#delay 0
#ChartColors (255,220,0) (0,255,255) (255,0,255) (0,160,255) (255,165,0) (60,210,90) (190,140,255) (255,120,120)
#ChartBackground black black (80,80,80) white - (180,180,180)
Normal/Light

Code: [Select]

#delay 0
#ChartReset
#ChartColors (255,220,0) (0,255,255) (255,0,255) (0,160,255) (255,165,0) (60,210,90) (190,140,255) (255,120,120)
But my script is more than that since it set Scales, Math, ChartScaleSync and all the resets.

I will take a look at it tomorrow.
But please include all colors, that is needed for a color scheme.
It is fine to add more line colors than standard, when using digital TC can use many more colors.

Note: It is possible to define a digital channel on the Math page with as many bit as needed.

[KungFuJosh]

@flash2b's color schemes should be fine.

I don't have anything set specifically, except to have popups use a white foreground with a background that matches their respective trace colors. If there was a way to automate that, that would be awesome. Like right-click a grid panel - "Background trace match" or something like that.

Thanks,
Josh

[HKJ]

@flash2b's color schemes should be fine.

What I am thinking about is added some buttons bellow the "Default" button in the layout/color popup, each one can preload the color overrides, that is easy to do.
In Flash2b posted example the colors looks nice for a dark scheme.

I will probably use the easy way to implement it, i.e. simply let the button run a script with the color statements.
It will also be easy to add more schemes later, but I only have space for a few buttons and I do not believe 50 schemes would be a good solution anyway. A few is better than many in this case.

I don't have anything set specifically, except to have popups use a white foreground with a background that matches their respective trace colors. If there was a way to automate that, that would be awesome. Like right-click a grid panel - "Background trace match" or something like that.

I can see why you want that, but I am not really in favor of implementing it.

[flash2b]

Preset buttons under "Default" that preload the color overrides sounds exactly right, and it is more than I expected. I will post a complete set with every color stated, including a proper Light one rather than one that leans on the default.

There is one more thing, and it is not about the graph colors themselves.

As it stands there is no relationship at all between a color in a definition and the color the graph uses. Either the definition author creates that relationship by hand, or the user matches it again every time. If I want a toggle button and its curve to match, I have to look up the color the graph uses and copy the literal value into the definition. Two places, two hard-coded triples, and nothing keeping them in step.

If the palette were an entity in TC and the reference were done by index, that disappears:

Code: [Select]

:color: paletteCol1
The definition then says "this is channel 1" and the palette decides what that looks like. Pick a different preset and the button follows the curve, without anyone editing a definition file.

This matters most on multi-channel devices. On my temperature modules there are six or eight channels, and on a scope the channel colors are part of how you read the instrument — channel 1 is yellow on the front panel, so it should be yellow in the graph too. That is not decoration, it is how you know which trace you are looking at. Worth noting that the first four colors I posted are already the usual scope channel colors: yellow, cyan, magenta and blue.

There is a reason for what is not in the set as well. Pure red and pure green are signal colors — instruments use them for warnings, limits and pass or fail — so scopes and similar equipment keep them out of the traces. That is why my set has a softened green and a salmon instead of a pure red. A curve should never look like an alarm.

The histogram is where this bites hardest today. It offers one color for all the graphs, so on a multi-channel device there is nothing tying a histogram to its channel. I am not going to set color 1, save, set color 2, save, and so on for every channel every time I set up a measurement, so for multi-channel work I leave it alone. With a palette index the histogram could just take the channel's color.

It would also remove the ordering problem I mentioned earlier: today a curve takes its color from the order it was added, so the same chart built in a different order looks different. With an index the curve takes the color of its channel instead of its position.

So if the palette is one entity in TC with several schemes under it, referable from a definition with :color:, and numbered the same way the graph numbers its curves, that would be a real gain. The presets solve the graph itself — the numbering is what would let a definition follow it.

[KungFuJosh]

I like that idea.

If we could define colors for the grid panel foreground/background in the definition file, that would also be fun.

[HKJ]

There is one more thing, and it is not about the graph colors themselves.

As it stands there is no relationship at all between a color in a definition and the color the graph uses. Either the definition author creates that relationship by hand, or the user matches it again every time. If I want a toggle button and its curve to match, I have to look up the color the graph uses and copy the literal value into the definition. Two places, two hard-coded triples, and nothing keeping them in step.

Initially the idea with the config colors was to match channel colors on a device and they do not change.

The issue with chart line colors is that they are variable, i.e. a specific channel may change color at any time. That makes them a bad color choice.

[HKJ]

If we could define colors for the grid panel foreground/background in the definition file, that would also be fun.

The panels are not stand alone items, they all have the same basicPanel, then one or more layout specific panels and then the actual panel. background color is probably at the basicPanel level and do not have access to anything specific on the panel.
That is one issue with synching panels to selected channel, another issus is that some panels support more than one channel.

Doing a command that could apply a list of colors to a list of panels backgrounds, would probably not be hard, but I am not sure how useful it would be. Looking at selected channel and select background from that would be much more work, because selected channel is specific to each panel type, i.e. I would have to code it for each panel type.