MaslowCNC / GroundControl

This is the Ground Control software used to control the Maslow CNC Machine
https://www.MaslowCNC.com
GNU General Public License v3.0
275 stars 122 forks source link

Lets remake Keeping up alarm! #808

Closed MarcinanProfesjonalista closed 4 years ago

MarcinanProfesjonalista commented 4 years ago

Maslow cuts become even more repeatable when we have low Position Error setting. I was looking for function that execute that error in python files for Ground Control. Where is that function? At this moment I'm getting that error every 30 sec and that make maslow useless. The only think I do when error occure is: read step number. Press stop and rewrite it -1 then press macro and start. Cuts becomes almost perfect. But still maslow is cnc and I must do it manually.

Where is this function trigger in python and where is execution code?

BarbourSmith commented 4 years ago

Gotcha. That error message is there for a reason and is usually a symptom of some other issue. Turning it off can result in less accurate cuts, however if you want to turn it off there is an option under settings (or possibly advanced settings) which lets you set the distance at which that error occurs. Setting that distance to a large value like 100 essentially will turn off the alarm.

MarcinanProfesjonalista commented 4 years ago

I don't want to turn it of. I want the "position error" trigger to set back GCode counter to "actual-1" and then keep on execution. Turning it off result in BAD sled moves. At the moment I could just run background script to keep track of GCode counter. When the notification poop ups it could restart cuting for me. But I think its easier to find trigger of error then replace code.

BarbourSmith commented 4 years ago

Gotcha. Gcode is tricky in that it isn't actually allowed by the protocol to go back one line in the gcode since each line relies on the router being in the position at the end of the last line before the next line is executed.

So jumping to "actual-1" isn't always going to be a safe thing to do. We could retract the bit and then add a new line which is something like G0 XXX YYY to move to where it should have been, then lower the bit to the correct depth, then keep going. But I think the thing to do is to figure out from a hardware perspective why the machine isn't keeping up.

Have you tried lowering the feedrate slightly?

MarcinanProfesjonalista commented 4 years ago

Yes. I was experimenting with feedrates. I optimally working at 1000mm/min but it break my blade once. I had to lower speed to default 800 and now I'm getting a lot of keeping up alerts. Yes. I'm getting Keeping up Error at lower speeds and even when 2mm above cutting material. I soldered my cables to motors so signal goes directly to motor boards and encoders.

The problem is in execution speed. It don't finish one move and goes 2 steps further.

What is normal Amperage for motors?

Strimmer1 commented 4 years ago

I was having a similar problem cutting arcs. I was getting my g-code from FreeCad. Small arcs were actually calculating backwards so the machine would jump forward and cut backwards in small increments. Each time it saw this instruction the Ground control would not keep up and error out.

I haven’t solved the problem from FreeCad directly. I just save a dxf file and run it through Inkscape to get a clean g-code file.

Steve Trimmer Sent from my iPhone

On Nov 11, 2019, at 11:23 AM, MarcinanBarbarzynca notifications@github.com wrote:

 Maslow cuts become even more repeatable when we have low Position Error setting. I was looking for function that execute that error in python files for Ground Control. Where is that function? At this moment I'm getting that error every 30 sec and that make maslow useless. The only think i do is read step number. Press stop and rewrite it -1 then press macro and start. Cuts becomes almost perfect. But still maslow is cnc and I must do it manually.

Where is this function trigger in python and where is execution code?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

MarcinanProfesjonalista commented 4 years ago

I think there is problem witch execution, because I had to cut "W" letter. And its made only from 8 vectors. It skipped half of them and goes directly between hills. Yea, after 3h of cutting it ruined my work. Settings 300 -:- 1000 mm/min can't keep up. It still got enough force to go thru walls. https://drive.google.com/file/d/1Q04aoaIhraS_Z73cmHkCUrraFsAvlpPJ/view?usp=sharing It don't finish one order and goes two further.

MarcinanProfesjonalista commented 4 years ago

Where is that function trigger in the code, I'm looking and looking and cat find it. Code 15226 is executed directly after code 15221 great. I'm restarting to 15221 and its skipping two steps to 15223 and says it can't keep up... no shit. I'm fighting with this for two days by restarting the cut.

BarbourSmith commented 4 years ago

The error message is generated in the firmware here:

https://github.com/MaslowCNC/Firmware/blob/7cc78df9fe2fc380c0ff5928e083416e5a5c9078/cnc_ctrl_v1/Report.cpp

Do you see the missing line sent to the machine? As in is the line being sent, but not executed, or is it not being sent?

Edit: If it's the former it might be worth testing with web ground control to replace that link in the chain to see if the issue is solved that way.

davidelang commented 4 years ago

the default value of 2 is way too small, try slowing down more , say 300mm/min and see if it keeps up.

David Lang

blurfl commented 4 years ago
Code 15226 is executed directly after code 15221

At present, the line number shown in GC reflects the line number most recently sent instead of the line number being cut.

There is a setting 'Buffer Gcode' at the bottom of the Maslow Settings page. The default setting is 'OFF' and in that state GC waits for the firmware to send 'ok' indicating that a gcode line has finished before sending the next one. When set this way, the line number in GC shows the line that the firmware is executing.

When the setting is 'ON' GC sends enough lines to fill the firmware serial buffer and the firmware is often a couple lines behind the line number that GC shows it has just sent. That sounds like what you're seeing.

If you change that setting, you'll need to quit GC and start again to make the new value take effect.

MarcinanProfesjonalista commented 4 years ago

Ok. I finally find the problem. When i was tightening the screws i removed encoder cover and tried to rotate it by hand. Too hard to rotate engine shaft. At night I've got -5°C in my garage and 15°C, that make my bungee old. I installed two more bungees for temporary use but that need to be rethink. Default value of 2 now works perfectly. When I finally get what is wrong i tested it on 3h reindeer model and it just went from begin to the end perfectly fine(I already got "keepin up paranoia"). Rly w/o any keeping up error. At the morning i will measure the amperage of power supply and try to find replacement for bungee because that solution is too expensive.

Remove bungees from maslow project. That can be added to Keeping up error description.

Can't go slower than 700mm/min because low PWM mean lower torque. (I don't know, do maslow engines on low feed rates uses low PWM) https://www.phidgets.com/docs/DC_Motor_and_Controller_Primer?utm_source=rb-community&utm_medium=forum&utm_campaign=pwm-affects-only-speed-or-torque-as-well#Pulse-Width_Modulation

BarbourSmith commented 4 years ago

That is fantastic news! Good sleuthing to figure out what was going on, I'm glad to hear it.

The speed an the PWM frequency are actually not related in the controller. The machine uses a PID controller to apply whatever torque is required to move to the correct position...unless of course full torque isn't enough power to get to the target position...then you see the error you were getting.