Problems with straight lines on Scara/Polar table

jkendric · May 1, 2022, 10:13pm

Hi everyone,

Hoping somebody might be able to help. I just completed a build of a scara machine utilizing some of the designs posted on this sight. I have the GRBL setup per instructions supplied throughout the site and the machine works really well with one peculiar exception. If I use designs with circles or arcs, it works perfectly, but any designs with long straight lines (ie the wipe/eraser design from sandify) each line will have a small curve inward towards the end (about 3/4 to the end) of the line. It is consistent and reproducible. The designs still look cool, but it kind of bugs me that the straight lines aren’t fully straight. Any ideas from anybody who has built these tables or used sandify for your gcode?

Thanks,
Jeremy

p.s. - I can post some video and/or pics if that would be helpful.

jeffeb3 · May 2, 2022, 12:58am

Pics would be great. Vids are great too, but you’ll have to post them elsewhere (like YouTube, or anywhere) and then post a link.

I am curious where the lines are. My first idea is some backlash, but I think that all the time. I’ll guess if I see the picture. Maybe someone else with a SCARA machine will recognize the issue.

I am assuming you are using the SCARA gcode output. I don’t have a good way to validate that. It would be nice if I could just paste it in a website like ncviewer and see that the turns aren’t in gcode.

jkendric · May 2, 2022, 5:25am

Thanks for the quick response Jeff! I knew you would be the right man for the question…

Here is the pic of the pattern in sandify, and then how it turned out:

I’ll work on a video when I have a second. Let me know what other information I can post. I am using the Scara GCode output, Max rho of 1 and units per circle of 6. Her is the Gcode file if that is helpful, but sounds like it is difficult to validate…

square.gcode (253.8 KB)

Anyway, thanks for taking a crack at it!

-Jeremy

jkendric · May 2, 2022, 5:32am

OK, here is a video. This is pattern imported from the JSisyphus example tracks into Sandify, then exported:

Here is a still of the closeup of a triangle that should, in theory have straight sides:

Here is the video of it in action:

Around 1:00 in is a great example.

Strange stuff. Thanks again!

Jeremy

jeffeb3 · May 2, 2022, 5:55am

I’m convinced I have it figured out. It took me a minute to find it.

In those lines, the “elbow” is pulling in (making the radius smaller) and that is a straight line. Then it flattens out and starts pushing out the elbow.

Right when it changes, the ball seems to follow a constant radius arc. You can see it in the video. The ball goes from a line to an arc, to a different line.

Then the ball starts tracking out again.

Your elbow joint has some backlash. When it is pulling in, it is hard against one edge of the backlash. When it starts reversing, it isn’t moving, just picking up that slack. Then it gets taught and starts moving again.

If you’re using GT2 pulleys, maybe the grub screw is loose on the flat of the motor shaft. If you’re using meshing gears, they might just be that loose. You can probably jog the elbow joint and see that when it changes directions, it doesn’t move immediately. If you can watch or feel it when it does that, you should be able to see where the slack is. Another approach is to just enable the motors (so they hold still) and wiggle the elbow to see where it is slipping.

It is really interesting to see how freaking sharp it is. You can see it in the images even. A straight line, and arc (on a constant radius), and a straight line.

Really nice build. Holy cow is that a clean looking build and almost no border.

jkendric · May 2, 2022, 11:13pm

You are incredible! I had some slack in my belts and tightened them up nice and snug, and wouldn’t you know it got rid of 90% of the issue:

I’m going to futz around with the pulleys and make sure there is no slack anywhere. Thank you SO MUCH for the feedback. You are a genius!

Also, thanks for the feedback on the table. Here is a look under the hood to anybody interested:

Thanks again Jeff. You are a sand table God!

JK

jeffeb3 · May 2, 2022, 11:28pm

That is a slick, compact assembly under there. Thanks for showing it off.

Are the files available somewhere?

Glad it is working better. I am sure you can make it nice and tight. Be sure to check the grub screws keeping the pulleys on the motor shafts. Those are the least obvious place for slack. They are commonly cause for issues on the CNC machines.

jkendric · May 3, 2022, 5:41pm

Thanks again!

All of the credit for the table goes to these forums. There are a couple of users that I pulled ideas from, but I used the files (from @woobag) at:

https://www.thingiverse.com/thing:5161882

as my basis and then customized the parts (arm length, etc) to fit the build. I used a planter bowl off amazon as the container and it worked pretty nice.

-Arduino+CNC shield+gcodesender on a Pro Micro (@karltinsly) (github) - with your helpful additions
-Using WLED as my LED controller.

Now onto building my MPCNC!

Thanks again -
Jeremy

jeffeb3 · May 3, 2022, 7:05pm

You’re using the gcode sender?! Nice!

jkendric · May 31, 2022, 11:16pm

Probably shouldn’t piggyback here, but hoping, Jeff, you might be able to give me some guidance.

I mentioned I am using the gcode sender arduino sketch. I am definitely an arduino/coding noob, but trying to hack it through. I am running into an issue that I am wondering if you could shed some light on.

When sending commands over serial in my code, is there something I need to keep in mind as far as timing? I am trying to set up a few commands such as an initial homing command, or a G92 to “reset” the position of the scara arm prior to drawing any given gcode files. Whenever I try to send subsequent Gcode commands via the serial interface, it seems to get all messed up.

If I keep it to a simple homing command, it generally works, but if I try, in the next line of code to send a G92 command, it seems to foul everything up. I am sure this has something to do with the arduino code moving along at it’s own speed, but no matter how many delay commands, etc I use, I can’t seem to send a subsequent GRBL command in the arduino code without things getting fowled up. I know that is a terribly vague request, and I can share the code with you, but a warning in advance! I have completely butchered the good work you and @karltinsly started in an attempt to fit my own application.

JK

robertbu · June 1, 2022, 12:17am

Are you sure the baud rate of your g-code sender and GRBL code match? Are you sending a newline at the end of your g-code commands? Do you still have a problem in you use RepetierHost to send manual commands?

jkendric · June 1, 2022, 1:39am

Thank you for the reply. The serial communication works great. I can pass code through just fine in real time (the serial commands are forwarding) it is when I try to send a command as part of the Arduino code but it gets messed up.

robertbu · June 1, 2022, 2:40am

Expanding on my previous post, your Arduino code needs to set the baud rate to be the same as GRBL is using. I don’t know GRBL’s default baud rate. If RepetierHost or similar is working fine, then you should be able to see how your other g-code sending code tools set the baud rate and copy that value. If you are using the standard Arduino serial library, you would set it in Serial.begin().

I know Marlin expects each g-code command to be separated by a newline. That may also be true of GRBL. If you are not sending a newline at the end of your g-code command, GRBL may have issues parsing the command.

There are a few Arduino programmers on the forum, so if you put your sketch in a ZIP file and upload it to a post, someone might be able to spot the issue.

jeffeb3 · June 1, 2022, 3:50am

I can’t remember how Karl’s sender decides to send another command. It is either waiting for a new line, or an “ok\n”. You definitely can’t just send commands as fast as you want. The receiving arduino has a limited buffer and it can overflow.

So my vague guesses are:

You need to wait for something like an “ok” before sending your next command or
The “ok” isn’t being handled by you, it is being handled by Karl’s code, so that code thinks it is ahead of where it actually is. You may need to read from the serial port after writing to make sure you clean out your own received buffer before starting the gcode.

If you paste some snippets, I can see if I can help more. Or if you’re still stuck, I will go reas Karl’s code again (it has been years).

robertbu · June 1, 2022, 4:34am

Interesting. I just did a quick search for “Arduino g-code sender.” There were several github projects. Looking at the first one, I found this function:

void checkForOk() {
  // read the receive buffer (if anything to read)
  char c,lastc;
   while (Serial.available()) {
    c = Serial.read();    
    if (lastc=='o' && c=='k') {awaitingOK=false;}
    lastc=c;
    delay(1);     
    }
}

It looks for the string ‘ok’ being sent back before clearing the awaitingOK flag, which is checked elsewhere and allows the next command to be sent. This function is called periodically until the ‘ok’ is found. I assume this would be true for GRBL and Marlin.

jkendric · June 1, 2022, 4:53am

Jeff and Robert,

Thank you both! You both arrived at the same conclusion at the same time. I was totally missing a “\n”.

That fixed everything! Robert, the github link I am using is posted up in my earlier post. Thanks to you both!

JK

jeffeb3 · June 1, 2022, 12:07pm

github.com

karltinsly/gcode-feeder/blob/master/serialGrblDEMOKTv3.ino#L263

      
        
            	String line = "";
            
            
    Serial1.print("\r\n\r\n");			//Wake up grbl
                delay(2);
                emptySerialBuf(1);
                if(myFile){                                                                      
            	    while(myFile.available()){		//until the file's end
            	    	line = readLine(myFile);	//read line in gcode file 
            	      	Serial.print(line);		//send to serials
            	      	Serial1.print(line);
            	      	Serial.print(getSerial(1));	//print grbl return on serial
            		}
            	}
            	else
            		fileError();
            
            
	myFile.close();
            	Serial.println("Finish!!\n");
            	delay(2000);
            }

Karl is going even simpler and just reading any line from the serial port. If it is ‘error\n’, he still continues.

The 1:1 message to ‘ok’ can be a bit dangerous. Because you can’t ever miss one, or you’re stuck. But you also need to be careful, because if you accidentally time out and skip ahead, then your command might be dropped, or cut off. It is a tricky balance. Cncjs has had trouble with this. The touch screens have trouble with it. It’s tricky.