You should look at your acceleration settings as they look like it could be causing some issues.
C3D LaserBoard uses hardware open drain inverters to create a common anode setup on the drivers.
When you are checking, also check if any of your step pins in the config file have a ! after the pin assignment. Can you tell each axis to jog a distance and measure that the distance is indeed correct?
Ok, thanks for the confirmation. I didn’t think I wired it backwards, but I will double check.
The config is pretty much stock except for steps/mm and max bounds and doesn’t have a ! inverting anything.
When I first set it up, I cut 25, 50, and 100mm squares and all of them were spot on. (Within 0.05mm anyways).
@LightBurn - Do you have the camera alignment file separately and could send it to me? I’m trying to reproduce the issue without going through the alignment wizard again but it works fine every time. For example, this was done at 120mm/s which is much higher than I ever used to run this machine with the old controller and software:
Perfect. There’s no artifacting on the square at all. I also tried with a filled circle in the middle, same thing. Looks perfect.
And I’ve even tried cranking the speed WAY up, thinking that the alignment wizard was maybe ignoring my speed… but I have the acceleration in my config set to 500mm/s/s (as opposed to the LaserBoard default 2500mm/s/s as it was in my old controller’s firmware, that it’s never actually reaching those higher speeds. I’d say it’s maxing out at 100mm/s on a 50mm square object.
So this leads me to believe that it’s either something with the vector file used in the wizard (and something weird with my machine that only shows up with that file). Or the wizard is doing something weird on the gcode output… having the vector file used would at least help me confirm it is or isn’t that specific design.
I even ran this raster engrave and it’s absolutely perfect. Zero evidence of any slop in the system or the laser firing at the wrong time.
And @raykholo - I’ve double checked my external driver wiring, and it matches (at least per the labels on the DM542) exactly the wiring you have shown in your docs:
It’s flipped upside-down, but same order. Same colors to same labels.
So @LightBurn this is why I wonder if it’s something specific to the alignment wizard.
If you guys have any specific ideas, great. If not, it seems to be working otherwise and maybe I can pick this up in the future and debug in detail for you.
Thanks!
@LightBurn - What’s the max size laser cutter you’ve seen used with the camera? Maybe it’s just a matter of where I’ve mounted it but I cannot figure out why it only works in the middle half. Basically a ~400x600mm area out of the 600x1200mm full area. Tried recalibrating a couple of times to no avail… still off by an increasing amount up to ~3mm at the edges.
@LightBurn & @raykholo
Ok, so I’ve tried the supplied camera alignment file and I can confirm it’s not related to the file or any specific settings. After I knew I could reproduce it with the full file I trimmed it down to just one of the targets and started testing. A wide variety of cut settings gave roughly the same results with that weird slant.
Next I thought I’d try with the settings from the provided alignment file but with something else. First I tried a simple circle and that turned out fine. Even with the outline traced afterwards, it lined up perfectly. A square worked fine as well. Even a basic triangle was fine.
So then I thought I would rule out that it’s the file given (don’t worry, I trust you @LightBurn, just gotta due my due diligence) so I redrew the target shape in InkScape and ran that… sure enough, it also has the same issue.
This was done at 3000 mm/min.
Out of curiosity, I tried much slower, 700 mm/min and sure enough the issue was much less apparent.
Given that it’s speed related I wonder if it’s semi related to the scan offset option that’s available in device settings. It does seem like the laser is lagging ahead or behind. But it’s weird that it’s specifically with pie shape. On another whim I wondered if it required having the radius on the long side, so I tried it again with a right triangle this time (last triangle was equilateral). And sure enough:
And the problem even scales with size. What’s weird is that the laser was firing in both directions so I’m not really sure how to tell if it’s firing ahead or behind where it should. And more… WHY only with this type of shape.
Any thoughts?
At least basic cutting and anything that’s not this specific shape seems to work without issue 
Had a random thought after sending that and decided to try the right triangles again, but with uni-directional scanning…
As you can see, I tried both directions and they are perfect.
As to why… I have zero clue what this means. But seemed pertinent.
Ok, that is bizarre. The slant I’ve seen before, when the step signal and motor driver don’t agree on whether it’s the rising or falling edge that signals the step. BiDir turned off means you get a sawtooth traversal instead of a square wave traversal, so that might still be the cause. See if there’s a way to invert the step pin output (which controller / firmware are you, Smoo? If so, I think it’s just ! after the pin).
Yep… I’m using the Cohesion3D board with SmoothieWare. Out of town for a few days but I will try inverting it when I get back. At least I have a specific way to reproduce it now.
No luck 
Updated config looks like this (just adding the ! as discussed on the step_pin)
alpha_step_pin 2.0! # Pin for alpha stepper step signal
alpha_dir_pin 0.5 # Pin for alpha stepper direction
alpha_en_pin 0.4 # Pin for alpha enable pin
alpha_current 0.4 # X stepper motor current
alpha_max_rate 24000.0 # mm/min
alpha_acceleration 2500 # mm/sec²
beta_step_pin 2.1! # Pin for beta stepper step signal
beta_dir_pin 0.11 # Pin for beta stepper direction
beta_en_pin 0.10 # Pin for beta enable
beta_current 0.6 # Y stepper motor current
beta_max_rate 24000.0 # mm/min
beta_acceleration 2500 # mm/sec²
`
This makes me wonder if it's just something weird with my machine... slop in the motion system or something? Sadly I can't really try it with the old control hardware without completely undoing all the work with the C3D board.Double check that I got that invert right - it should change the output, and doesn’t appear that it has. It’s not slop - it wouldn’t be that perfect, and wouldn’t be cumulative.
The config.txt file documents what you said for inverting the step_pin as correct. Maybe @raykholo would know more?
It might need to precede the pin number, not follow it - worth checking. As I said, I’d expect that change to alter the output, but it doesn’t look like it did.
I’ll give it a shot later today, but according to the docs, after is correct:
http://smoothieware.org/pin-configuration
The above usage is correct(2.1*) with asterisk being your modifier, same way you would pull a pin high(^) or low(v), set to open drain(o) or invert(!).
Are you saying I should’ve used alpha_step_pin 2.0* instead of alpha_step_pin 2.0!?
I’m a little confused by your comment.
He’s saying that the modifier (punctuation mark, of which there are several) goes after the pin assignment number. You have 2.0! correct in your example. Smoothie can do other things, like 2.0o and 2.0!o, which should be outside the scope of what you need.
1 Like
@raykholo - Ok, cool. So now I guess the question is why did inverting the step pin not really change anything?
Is there a setting in Smoo for the duration of a step pulse? I wonder if extending that might help?
http://smoothieware.org/configuration-options
http://smoothieware.org/motion-control
microseconds_per_step_pulse ?