coelacant1 / opendact Goto Github PK

I used serial port sniffer to locate this issue.

My z-probe is located 12.4mm below the nozzle on a hinge. The value is entered in EEPROM:

EPR:3 808 12.400 Z-probe height [mm]

For some reason OpenDACT corrupts it. When I open the program and use "check current heights", it probes once, then sends this:

M206 T3 P808 X5.280

and, almost immediately, this:

M206 T3 P808 X5.280

In the program the value gets displayed as 5.2799999

Why would it touch this value, it should be treated as a constant?

I realy would like to see this tool working with Marlin so until that is there a easy way to translate Alpha Rotation, Delta Radius, XYZ offset, Horizontal Radius, and Diagonal Rod length to Marlin ?

I've tryed the program (latest binary on the the git) but looks like with the Repetier 0.92 we have some issues.
The program behaves really randomly, only zprobe one point near the bed center, seldomly crashes into bed.
Tested on Windows 10 host with . as decimal separator.

Clicking on the forum post in README does not take the user to the forum post. It's a very minor error, but newbies won't know how to fix and may give up.

Instead of:
Forum post - http://forum.seemecnc.com/viewtopic.php?f=36&t=8698
It should display:
Forum post - http://forum.seemecnc.com/viewtopic.php?f=36&t=8698

Testing OpenDact Version 3.0.0 (Abbout Button is promting this Version) I downloaded it from the seemecnc Page as 3.1.0A

I use the newest Repetier Firmware. Connecting works but thats it. Is there somethings else to mention?

Recently I've upgraded my printer with a better tact button that serves as a Z-probe and understood my problem with OpenDACT giving me "wild" results. Turns out that "noisy" data from an unreliable z-probe break the calibration algorithm and OpenDACT ends up with some crazy settings.

To prevent users like me from shooting ourselves in the knee, I suggest the following feature: if the accuracy is set too low (or the program runs for the first time), do a series of probes in a single point and calculate std.dev. If it is bigger than the demanded accuracy stop the calibration and ask the user to reconsider.

Hello. I'd like you to consider a feature request: let the user "lock" certain parameters and make an algorithm exclude them from calculations. For example, I am 100% certain my "steps per mm" value is correct, so I'd prefer OpenDACT to avoid touching it.
When a z-probe isn't very reliable and produces "noisy" measurements, OpenDACT ends up increasing "steps per mm" incrementally without much success (usually it makes things worse). If that could be "locked", it'd force the program to try other tweaks instead.

OpenDACT (latest trunk version) crashes as it issues commands like this:

17:58:12.448 : M206 T3 P921 X-0.783469

Probably since it has 6 decimal numbers and not 3 (as Repetier uses to store floats in EEPROM), log starts filling up with lines like this and app freezes:

`000356: 0
FlowMultiply:100
ok 0

000357: 0
FlowMultiply:100
ok 0
SelectExtruder:0
FlowMultiply:100

000358: SelectExtruder:0
FlowMultiply:100

000359: SelectExtruder:0
FlowMultiply:100

000360:
Resend:1
ok

000361:
Resend:1
ok

000362:
Resend:1
ok

000363:
Resend:1
ok

000364:
Resend:1
ok

000365:
Resend:1
ok

000366:
Resend:1
ok

000367:
Resend:1
ok

000368:
Resend:1
ok

000369:
Resend:1
000370:
ok

000371:
ok

000372:
Resend:1
ok

000373:
Resend:1
ok

000374:
Resend:1
ok

000375:
Resend:1
ok

000376:
Resend:1
ok

000377:
Resend:1
ok

000378:
Resend:1
ok

000379:
Resend:1
ok

000380:
Resend:1
ok
`

Hello. Sometimes OpenDACT may produce negative values and try saving them in EEPROM.

Repetier discards these and saves zeroes to EEPROM instead. Yet it seems that OpenDACT thinks printer uses those negative values. In practice this usually leads to nozzle crashing into the bed on the next iteration.

I suggest checking for negative offset values (or, more broadly, negative values being suggested for any parameter) and checking for too big values (like offsets of 2000+ steps).

It appears that the program is having issues working in Windows with non-US locale set.

I have Windows 10 64bit with Russian locale; it uses comma, not point as a decimal delimiter. All the numbers that appear in the main window are displayed with a points before decimal parts.

But it seems that internally the program operates with correct localized functions - and crashes when it sees the "wrong" decimal delimiter.

If I create a temporary Windows account and set its locale to UK or US, program works.

Maybe the problem is that reading EEPROM always gives you the numbers with decimal point as separator. In US locale treating these strings as numbers just works, in Russian locale it doesn't.

Please check this for details: https://msdn.microsoft.com/en-us/library/system.globalization.numberformatinfo.numberdecimalseparator%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396

Please consider fixing these 2 annoyances in the interface:

• make OpenDACT enumerate all COM ports and pre-select port with largest index on startup. On my system it always chooses hardware port COM1 instead of virtual COM4. Since OpenDACT crashes a lot, choosing correct port every time is annoying.
• please add default value of "G28" to "send GC" input. Please also make the program send the command on "Enter"

Thanks!

Hi,
when tOpenDACT (3.1.0A) read data from eeprom it read without the decimal dot, so 200.000 steps/mm become 200000 steps/mm and so on the other numbers. I can see the right number in the log, but i read wrong number in the "advance" tab.

Where i press the "Check Current Heights" i have to shut down the printer because the carriage go towards one column moving nearly horizontal.

Bye

Hello. I'd like to suggest a feature request. It would be great if OpenDACT would keep an CSV or tab-delimited file (or just snapshots of the EEPROM listings) and update it on each iteration. Sometimes OpenDACT achieves an amazingly accurate calibration yet decides to try once again - and ruins the result. If there was a way to find the record of the previous result and manually input it to the printer, it could be great.