OpenDACT(Delta Automatic Calibration Tool) - For Repetier

[mhackney]

Ok, I just got back from my business trip and have a Windows 8 laptop so I am good to try this. I would actually like to start with my Mini Kossel as it has a Rambo running Repetier and FSRs. Is it possible to change the sampling positions to work with the mini kossel?

[mhackney]

Ok, I am deathly afraid of running this and having it automatically set things in EEPROM and screw up what is a reasonably good calibration right now. I do have a few issues that I'm hoping something like this will calibrate but I can't afford to hose what I have.

When I connect to my Rostock I see:

Connected
Reading EEPROM values

And nothing else happens. I an open the Advanced tab and More... to see the full window like the screenshot above. Dare I hit Advanced Calibration? Does it automatically update EEPROM settings? I've made a snapshot of my current settings but I'm still a bit apprehensive.

[mhackney]

So, has anyone got the 2.0.1 application working and calibrating? It seems the only successes have been with the HTML form.

I have Windows 8.1 Enterprise on a laptop now. I am running Repetier .92.3 on an Azteeg X3 Pro board. I can now launch the 2.0.1 exe and it comes up, I can enter the required fields and Connect and see the Connected status and Reading EEPROM values and then it appears that nothing happens after that as per my previous post. Has anyone gotten further with 2.0.1 and if so, what is your config?

[RollieRowland]

So, has anyone got the 2.0.1 application working and calibrating? It seems the only successes have been with the HTML form.

I have Windows 8.1 Enterprise on a laptop now. I am running Repetier .92.3 on an Azteeg X3 Pro board. I can now launch the 2.0.1 exe and it comes up, I can enter the required fields and Connect and see the Connected status and Reading EEPROM values and then it appears that nothing happens after that as per my previous post. Has anyone gotten further with 2.0.1 and if so, what is your config?

Figured this may happen, you're the first person to test that version. So there are bugs that I haven't worked out yet. For now, try to use version 2.0.0. I haven't been near my printer in about a week.

Edit: I will be able to fix this issue on Monday.

Edit 2: Here is the current source code, as per request - https://drive.google.com/file/d/0B06WCA ... sp=sharing

Edit 3: This will modify your printers EEProm values. Also, for your question about the Kossel, yes. That is the reason for the build diameter being required. It calculates the position of the gcode with that diameter.

Edit 4: I was just digging through the source code, I haven't found any issue (yet).
A few things that you could try:
-open the advanced panel and see if any information is coming from the printer i.e. "wait"/"ok"
-connect to the printer in your host software and send m205, then wait and see if the EEProm is sent/check how long it takes (my baudrate is 250000). Also check the formatting of the EEProm, mine reads as "EPR:2 75 250000 Baudrate". If yours is different then my data parser will need set up differently.

[mhackney]

Thanks RollieRoland, I grabbed the sources and will look them over to see what I can find.

On 3 - I will use my mini kossel for testing then!

4 - no, I'm not getting anything from the printer. M205 returns instantaneously and fetches all of the EEPROM (that's how I make a snapshot of my settings too). My baud is 250000 also.

Mine: < 8:51:39 AM: EPR:2 75 250000 Baudrate

So we are the same on that.

Let me try the v2.0.0 to sanity check. If that worked for others, it should work for me and help determine if I have a config issue or software bug.

[mhackney]

Ok, this is different...

I downloaded 2.0.0. It connects, fetches EEPROM settings and displays the transformation matrix - and then crashes. This is on Windows 8.1 Enterprise on a ThinkPad (12 month old one) with my Rostock running an Azteeg X3 Pro. We'll pull out the kossel that has a RAMBo and check that.

[mhackney]

Ok, with 2.0.0 connected to a RAMBo on a mini kossel it connects, and displays fetching EEPROM and hangs.

I've gone through this entire thread yet one more time looking for folks who are using the exe. I didn't find one so perhaps no one is able to get the application to work yet?

[RollieRowland]

Ok, with 2.0.0 connected to a RAMBo on a mini kossel it connects, and displays fetching EEPROM and hangs.

I've gone through this entire thread yet one more time looking for folks who are using the exe. I didn't find one so perhaps no one is able to get the application to work yet?

No the error is coming from the difference of our EEProm results when the m205 command is sent. Your extra time in front of the results threw off my parser. I will add a way to parse yours today, that will probably fix the issue.

While you are at it, can you send the g30 command to check the height of the z-probe and tell me what it returns? That way we can make sure the program works first time.


My parser that checks the EEProm relied on checking the first word of the data coming from the printer. With your printer it reads the date and passes it off as something else. I am going to completely redo how the parsing is done, I'll let you know what I figure out.

[mhackney]

Intersting, yours doesn't show the time in the log messages? I wonder why not?

I'll have to wait until this print is done to test the G30.

[mhackney]

For better or worse, I've implemented more than my fair share of parsers over the last 30 years! Have fun.

[RollieRowland]

For better or worse, I've implemented more than my fair share of parsers over the last 30 years! Have fun.

Oh I'll try! This time I will definitely make it more versatile.

[mhackney]

Ok, I have the mini kossel G30 results:

Z-probe: 10.66 zCorr: 0

This machine has FSRs on it so I would have expected Z-probe = 0, right?

[RollieRowland]

Ok, I have the mini kossel G30 results:

Z-probe: 10.66 zCorr: 0

This machine has FSRs on it so I would have expected Z-probe = 0, right?

The space between "Z-probe:" and "10.66" was from the printer? Need to make sure so I can get correct syntax.

I would assume that you should've gotten zero, although do you know what your Z-probe height was set to in the EEProm? It could've altered that returned height.

[mhackney]

No, the Z probe touched the surface and reported 10.66

I don't know what it is in firmware, I'll have to check. This is my son's printer and the config is on his MacBook.

[RollieRowland]

No, the Z probe touched the surface and reported 10.66

I don't know what it is in firmware, I'll have to check. This is my son's printer and the config is on his MacBook.

That would have to mean that the probe height in the EEProm isn't set to zero, not necessarily an issue either way.

I am almost finish with the new parser. It now checks if the data from the printer contains "Z-probe" or "EPR", and then splits accordingly. It will work with any form of return, as long as the values are in the same order.

[mhackney]

I have the 2.0.1 sources compiling under .NET framework 4.0 on Mono on Mac

And I can connect to the printer from the Mac/Mono version. Running into "Reading EEPROM values" and hanging so I'll wait for the parser update.

[mhackney]

Z_PROBE_HEIGHT is 0 in the firmware.

[mhackney]

Hmm, in the EEPROM settings there are 2 things:

Z-probe height 0mm
Max. Z-probe - bed dist. 10mm

The Z travel goes fast until it reaches the bed list and then slows at that point to do the touch off. If I change the Max. Z-probe - bed list. to 5mm the reported G30 is 5.64mm (there is a little variation in the 1/100smm place). Something is odd.

When I do this on my Rostock, where these are set to 0 and 5mm, the hot end lowers fast to 5mm then slows and touches off but does not report any values! What's up with that.

[RollieRowland]

Z_PROBE_HEIGHT is 0 in the firmware.

Same for the EEProm? Check for this with the m205 - "11:33:52 AM: EPR:3 808 10.66 Z-probe height"

I don't know what else to suggest... but if anything you can just reset your z-height after calibration.

This should work based on the data you've given me, and of course still assuming there wasn't another issue that I may have missed somewhere else. This will still work if there is not a time too.
https://drive.google.com/file/d/0B06WCA ... sp=sharing

Quick explanation of the fix:
-input data:"11:33:52 AM: EPR:3 808 10.66 Z-probe height" or "EPR:3 808 10.66 Z-probe height"
-split string at "EPR"
-left with ":3 808 10.66 Z-probe height" or will even work with ": 3 808 10.66 Z-probe height"
-uses "808" to find the appropriate setting
-uses "10.66" as the value

Mine doesn't even have that setting... but if it affects the height then I would consider setting it to zero and use the speed control in the program. It will go fast until Z100 and then will go the probing speed. So your Rostock doesn't report any probe distance? That has to be in the firmware.

Edit: Completely missed the post that you had this operating on Mac, here is the updated source - https://drive.google.com/file/d/0B06WCA ... sp=sharing

[mhackney]

Opps, I had Info logging off in RH on my Rostock config. I now see it reports back Z-probe: 6.39mm

Again, very odd! I've looked through the firmware configuration.h and the EEPROM and can't see why it isn't setting to 0. My machine (both actually) are calibrated for Z=0 right at the point of contact as seen by the FSRs.

[mhackney]

Yes, I checked both machines with the EEPROM window and M205.

Rostock:
< 11:45:59 AM: EPR:3 808 0.000 Z-probe height [mm]
< 11:45:59 AM: EPR:3 929 5.000 Max. z-probe - bed dist. [mm]

Kossel:
< 11:47:02 AM: EPR:3 808 0.000 Z-probe height [mm]
< 11:47:02 AM: EPR:3 929 10.000 Max. z-probe - bed dist. [mm]

And in both cases, the firmware is set to the same.

Ok, I'll try the new post, is there source also? I'd love to see this work on OS X.

[RollieRowland]

Opps, I had Info logging off in RH on my Rostock config. I now see it reports back Z-probe: 6.39mm

Again, very odd! I've looked through the firmware configuration.h and the EEPROM and can't see why it isn't setting to 0. My machine (both actually) are calibrated for Z=0 right at the point of contact as seen by the FSRs.

Well it really shouldn't give you a problem, but it may not set the Z-height correctly. Everything else should operate properly though. One thing you could do is use the FSR plate offset and add(or subtract be careful) your 6.39 value to(from) that.

I threw the source link on the previous post in an edit, but here it is - https://drive.google.com/file/d/0B06WCA ... sp=sharing

[mhackney]

I couldn't install it on Windows - get an error that it is already installed. This is why I keep away from Win8, I have no idea what I'm doing on it.

I compiled under OSX Mono but get stuck at the "Request to read EEPROM sent" and then nothing happens.

[RollieRowland]

I couldn't install it on Windows - get an error that it is already installed. This is why I keep away from Win8, I have no idea what I'm doing on it.

I compiled under OSX Mono but get stuck at the "Request to read EEPROM sent" and then nothing happens.

Yeah, this messed with me a couple times, go ahead and directly use the .exe provided in the folder. It supposedly installs but I could never find it. The .exe link will open though.

This could either be a difference in how OSX uses COM ports or an issue with the program. We'll get it working on Windows first to figure out which it was.

(The .exe is not a published build, it is just pulled from the debugging folder.)

[mhackney]

Ok, I figured out how to uninstall and reinstalled the new version on Win8. I am running into the same issue as on the Mac:

Connected
Request to read EEPROM sent


and then it hangs. I have to ctrl-alt-del to kill from task manager