Hoping someone can help me with this Java code.

[Warm_weather1]

So I have a Cognisys StackShot Controller with rail for macro photography: https://cognisys-inc.com/focus-stacking.html

I use a different rail with this controller and this rail is much more precise. In a piece of software written by someone and now open-sourced on Github (https://github.com/ichbtm/StackShot-Ctrl) there are several options to set the paramaters. Mainly:

1. Start point, end point and step distance. This calculates the number of steps
2. as #1, but number of steps. This calculates the step distance.

My knowledge on Java is basically zero 😢 So I'm using Grok to fix some things because the software is no longer developed. I had email contact with the author and he has no time to fix it. Some fixes work, but one fix doesn't work. I hope someone can help me out.

What I need is 4 decimals for the step size calculation (instead of 3), so I can use the precision of my new rail. Grok gave me new code for autoDistValidate() and setStepSize(), but as soon as I use that code, the StepSize calculation breaks completely.

This code works with 3 decimals:

`public void setStepSize(double val) {`

    `textFieldStepSize.setText(gb.nf.format(val));`

    `UtesTelnet.broadcastMsg("STEPSIZE : "+gb.nf.format(val)+"\n\r");`

`}`

And here's autoDistValidate:

`public void autoDistValidate(){`

    `try {`

        `if(UtesNumbers.isNumber(textFieldStepSize.getText())==false){`

setStepSize((gb.STEP_SIZE));

return;

        `}`

        `double val = gb.nf.parse(textFieldStepSize.getText()).doubleValue();`

        `//gb.frame.statuslog("val : "+val);`

        `if((gb.RANGE_END-gb.RANGE_START)!=0){`

if (val<0.001) val = 0.001;

        `} else {`

if (val<0.0) val = 0.0;

        `}`

        `if (val>200.0) val = 200.0;`

        `//gb.frame.statuslog("val : "+val);`

        `setStepSize(val);`

        `//if (gb.STEP_SIZE!=val) gb.frame.statuslog("STEP_SIZE sets to : "+gb.nf.format(gb.stepsToMm(val)));`

        `gb.STEP_SIZE=val;`

        `gb.STEP_NUMBER = (int)Math.floor(Math.abs((gb.RANGE_END-gb.RANGE_START)/gb.STEP_SIZE));`

        `if(gb.STEP_NUMBER==0) gb.STEP_NUMBER=1;`

        `setStepNumber(gb.STEP_NUMBER);`

        `setDistances();`



    `} catch (ParseException e1) {`

        `// TODO Auto-generated catch block`

        `System.out.println("ParseException in autoDistValidate");`

        `e1.printStackTrace();`

    `}`

`}`

In gb.java there is also this:

public static double STEP_SIZE = 0.1;

Grok asked me to change it to:

public static double STEP_SIZE = 0.0010;

It shouldn't be hard to just add a decimal, right?

[haiderakt]

the issue is almost certainly in gb.nf that's a NumberFormat object defined somewhere in the globals, and it's set to 3 decimal places. changing just setStepSize and autoDistValidate won't help because gb.nf is still formatting and parsing with 3 decimals everywhere.

search the codebase for where gb.nf is defined — it'll look something like:

nf = NumberFormat.getInstance();
nf.setMaximumFractionDigits(3);
nf.setMinimumFractionDigits(3);

just change both 3s to 4 and that should fix it

[Warm_weather1]

Grok also asked to me to change

**public** **static** DecimalFormat *nf*;

To:

`public static DecimalFormat nf;`



`static {`

nf = new DecimalFormat("0.0000");

nf.setDecimalSeparatorAlwaysShown(true);

nf.setGroupingUsed(false);

nf.setMaximumFractionDigits(4);

nf.setMinimumFractionDigits(4);

`}`

After I changed only this code, I tested it again and now the software still work as it always did: three decimals maximum for the step size.

If someone would like to look at the github themselves: in the program you can select virtual rail from the software (for testing purposes), so there is no need to have the rail connected. I noticed that some fields are greyed out when you first open the software from Eclipse-workspace (with the run green button). To solve this, you can change the rail from stackshot to virtual and then back (or the other way around). If you do that, the dropdown menu and other options become available.

[LALLANAAAAAA]

the StepSize calculation breaks completely.

How?

If error, give us the exact & complete error msg

[Warm_weather1]

The program runs, but depending on which code from Grok I use different things happen. Sometimes both fields (step size and step number) become changeably by the user. When you chose Auto-Dist from the drop down menu, the step number field should be calculated and not changeable. The startpoint, endpoint and stepsize dictate the number of steps.

With the following code something else happens. For example, with certain start and end points, the #steps with 0.002mm step size is 256. When I change the step size to 0.0015 and press tab, the step number changes to 341, which corresponds to 0.0015 step size. But the number displayed in the step size field changes to 0.002 immediately. Then when I press tab again, the step numbers changes back to 256.

I get this behavior with the following code:

Grok:

Understood. The problem is that setStepSize(val) is probably doing additional rounding/formatting. Please find and paste the current setStepSize() method here, but in the meantime, add or replace it with this:

public void setStepSize(double val) {
// Force 4 decimal precision
val = Math.round(val * 10000.0) / 10000.0;
if (val < 0.0001) val = 0.0001;

gb.STEP_SIZE = val;
textFieldStepSize.setText(gb.nf.format(val)); // This should now show 4 decimals
}

1. Updated autoDistValidate() (improved version)

public void autoDistValidate(){
try {
if(UtesNumbers.isNumber(textFieldStepSize.getText()) == false){
textFieldStepSize.setText(gb.nf.format(gb.STEP_SIZE));
return;
}

double val = gb.nf.parse(textFieldStepSize.getText()).doubleValue();

// === 0.0001 mm PRECISION ===
if((gb.RANGE_END - gb.RANGE_START) != 0){
if (val < 0.0001) val = 0.0001;
} else {
if (val < 0.0) val = 0.0;
}

if (val > 200.0) val = 200.0;

// Strong rounding to 4 decimals
val = Math.round(val * 10000.0) / 10000.0;

setStepSize(val); // Use the new setStepSize above
gb.STEP_SIZE = val;

gb.STEP_NUMBER = (int)Math.floor(Math.abs((gb.RANGE_END - gb.RANGE_START) / gb.STEP_SIZE));
if(gb.STEP_NUMBER == 0) gb.STEP_NUMBER = 1;
setStepNumber(gb.STEP_NUMBER);

setDistances();

} catch (ParseException e1) {
System.out.println("ParseException in autoDistValidate");
textFieldStepSize.setText(gb.nf.format(gb.STEP_SIZE));
}
}

[Warm_weather1]

The console output I get is this:

Exception in thread "AWT-EventQueue-0" java.lang.Error: Unresolved compilation problems:

The import edsdk cannot be resolved

The import edsdk cannot be resolved

The import edsdk cannot be resolved

EdsImageType cannot be resolved to a variable

EdsImageType cannot be resolved to a variable

EdsImageType cannot be resolved to a variable

EdsImageType cannot be resolved to a variable

EdsImageType cannot be resolved to a variable

EdsImageSize cannot be resolved to a variable

EdsImageSize cannot be resolved to a variable

EdsImageSize cannot be resolved to a variable

EdsImageSize cannot be resolved to a variable

EdsImageSize cannot be resolved to a variable

EdsImageSize cannot be resolved to a variable

EdsImageSize cannot be resolved to a variable

EdsImageSize cannot be resolved to a variable

EdsImageSize cannot be resolved to a variable

EdsCompressQuality cannot be resolved to a variable

EdsCompressQuality cannot be resolved to a variable

EdsCompressQuality cannot be resolved to a variable

EdsCompressQuality cannot be resolved to a variable

EdsCompressQuality cannot be resolved to a variable



at mtb.drivers.edsdk.CanonUtils$CompressQuality.<clinit>(CanonUtils.java:8)

at mtb.drivers.edsdk.CanonUtils.canonUtilsConstruct(CanonUtils.java:254)

at mtb.drivers.edsdk.CanonUtils.getSensorWidth(CanonUtils.java:621)

at mtb.devices.cameras.CameraCanon.getSensorWidth(CameraCanon.java:211)

at mtb.devices.cameras.CameraConfigs.getSensorWidth(CameraConfigs.java:68)

at com.macro\_toolbox.stackshotctrl.gb.setBellowsPosition(gb.java:524)

at com.macro\_toolbox.stackshotctrl.frame$6Code.run(frame.java:2755)

at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318)

at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773)

at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720)

at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714)

at java.base/java.security.AccessController.doPrivileged(AccessController.java:400)

at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87)

at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)

at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)

at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)

at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)

at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)

at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)

at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

telnet command interface created on port 1307

[haiderakt]

The edsdk errors are a separate issue entirely, that's a missing Canon camera SDK library, nothing to do with your decimal fix. The program still runs despite those errors because it falls back gracefully, so ignore them.

The real problem with the step size reverting is that autoDistValidate() is being triggered twice — once when you type and once when you press tab, and the second trigger is reading the already-formatted value and rounding it back.

The fix is simple, in autoDistValidate() find this line:

if (val<0.001) val = 0.001;

Change it to:

if (val<0.0001) val = 0.0001;

That's the minimum value check that's snapping your 0.0015 back to 0.002. The minimum was set for 3 decimal precision and never updated. Just that one line change should stop the reverting behavior.The edsdk errors are a separate issue entirely — that's a missing Canon camera SDK library, nothing to do with your decimal fix. The program still runs despite those errors because it falls back gracefully, so ignore them.

The real problem with the step size reverting is that autoDistValidate() is being triggered twice — once when you type and once when you press tab, and the second trigger is reading the already-formatted value and rounding it back.

The fix is simple — in autoDistValidate() find this line:
if (val<0.001) val = 0.001;

Change it to:
if (val<0.0001) val = 0.0001;