There is an update to the tft coming. But I am still skeptical of that tft mode. I don’t think the handshaking is terribly robust.
I was not aware of anything wrong with the LR version. I will open an issue to track it. Unlike the dual xy, this does have a right and wrong way to it (they need to move the same way).
It sounds like you flipped the wrong motor. Bummer. There are firmware settings to reverse the motors. If you want to recompile it.
It should have a max distance it travels, not a max time. There is a Z height setting which it is probably using, but I think it is 200mm or something. When you send a 10mm movement, does it move 10mm? At any rate, I would not waste too much time worrying about homing and probing until the machine is moving the right way, with the right distances. These things are all interdependent and once you fix the movement, you don’t want to have to undo some fix for the probing.
What I would suggest as a next step is to try to get the dual lr firmware building (using platform io) and then we can figure out what settings need to be changed and give you the power to change them. Then after you are running I can work on getting those changes back into the MarlinBuilder releases. I can’t work on firmware today, or probably for at least a week.
Oh, ok, because of the release note I thought it was a known issue. It’s like you say, both Z steppers need to move in the same direction and that wasn’t the case. Although before flashing they both ran correctly
It’s my own fault, I imagined that reversing in the settings would have taken care of it. Probably most users just flip the plug, so this bug didn’t get noticed just yet.
If I find the time I’ll just resolver them once more.
I have yet to measure it, but as far as I can see it’s indeed 1cm move.
[ quote=“jeffeb3, post:62, topic:28733”]
I can’t work on firmware today, or probably for at least a week.
[/quote]
No worries! I will see that I can free some time to figure this out. But it will take some weeks as I am entering a busy time at work.
Also, as a BTW, reversing any coil, or switching the coils reverses the direction. If you are flipping a plug, it is easy to go from 1234 to 4321. If you are cutting and soldering, you can get away with just flipping one coil. Going from 1234 to 2134 is the same.
It is kind of interesting to see how reversing the plugs results in reversing the stepper:
1234 -- original wiring
2134 -- reversed
2143 -- original
4321 -- reversed
I rewired the steppers, and swapped the Z axis back to normal.
Strange thing is, now the G30 command no longer responds
Using the G38.2 Z0 command in terminal works just fine to probe, no matter how high or how long it needs to run. However… once using it in a script, it only probes like for 3 seconds and then stops probing by throwing an error.
I used the following, not sure if anyone spots an error I might have made?
G90 ; Absolute positioning, just in case
G92 X0 Y0 Z0 ; Set Current position to 0, all axes
G00 Z20.0000 F500 ; Raise Z 20mm at 8.3mm/s to clear clamps and screws before homing
G38.2 Z0; Probe Z axis
G92 Z14.0000 ; Account for probe thickness
G00 Z24.000 F500 ; Raise Z probe off of surface by putting it 10mm higher then probe
M00 ; pause for LCD button press to remove probe
I was thinking that it may be caused because I first set Z axis to 0, before starting to probe and re-defining 0 afterwards.
Anyways, because I wasted enough time, I set my Z axis close to the workpiece and ran the code. Including the limited probing.
Now I only need to figure out how fast to run the speed on my Katsu clone. I gambled and activated it just between max & low.
I also believe my machine isn´t completely square. On (only) 1 part of the crown I can see that the first layer isn´t positioned exactly the same as the following ones.
Going to read some other topics to find out how to fix this
You’re using the carve function, which uses the bit shape to decide how deep to move the tool. As the tool goes deeper, the width at the surface is smaller. If you look at the preview in estlcam, you can see that the bit lifts in those corners. It does this to get the fine precision in the carve.
That depends on the angle of the V bit. If estlcam thinks the bit is wider than it is, you will get shrinkage in the corners. If estlcam thinks it is smaller, you will get these kind of dogbones.
So my guess is that you are either using a flat bit to carve, or you have the wrong angle set for the bit you have.
Many thanks, going to try this one!
It makes sense to me know that you´re pointing to that. I use a 3mm flat bit, so that would be impossible to lift the bit in the corner like a V bit
What would be your suggestion for this? When importing PNG or JPEG it gives me the option to carve, laser and something else, but not the others.
Should I really try to convert my PNG to DXF and then towards Gcode?
I didn’t realize estlcam could do a carve with a png or jpg. Interesting!
I know what would work, is to convert it to svg by using inkscape.
import the png into inkscape
use the bitmap tracing tool. There are some good videos, or here is some documentation. It basically converts picture shapes into edges in svg: Inkscape tutorial: Tracing bitmaps | Inkscape . A black on white image like that will be easy.
delete the imported image.
You may have to convert the traces to paths by using the convert object to path tool.
save as svg
Import the svg into estlcam and the. Choose pocket.
Estlcam also has a basic text tool. I would make a dxf with the rectangle shape of my workpiece. Open that in estlcam and then add text.
IDK what affinity is. I am not an expert at these graphic design programs. I do know that svgs can store fancy objects like ovals, arcs, rectangles, text, or it can store the same shapes as paths. In inkscape there is an object to path button. I have better luck saving svgs that only have paths for estlcam. Maybe affinity can also convert the text to paths before exporting it as svgs.
In the past I´ve used Adobe suite a lot, that´s until they swapped to a monthly fee. As I didn´t use it that much anymore I couldn´t get myself to pay a monthly license. So that´s how I came across Affinity.
They are a competitor for Adobe, with low one off fee. They are great, although sometimes they have some missing features like in this case export to DXF.
But you´ve given me a lead, I think I did not convert my text to path/curves/outlines before exporting to SVG. So should try to do this. And if not working, try to convert to DXF.
Regarding Inkscape, I think I´ll try to convert using Photopea | Online Photo Editor instead, as it is compatible with photoshop and can export to DXF.
I am sure there will be many new chapters soon!
Small update on my probing challenge;
I´ve successfully managed to probe. However for some reason the Z refuses to lift after probing to the predefined height, so I could remove the probe.
I used the following 2 scripts, but no luck for the G0 and G1 command. If someone spots my error, please share!
G21 ; Set units to millimeters
G90 ; Absolute positioning, just in case
G38.2 Z-400.000 F500 ; Probe Z from max Z height, in case it was homed
G92 Z14.000 ; Set Probe offset to 14mm, thickness of probe
G92 X0 Y0 ; Set X Y axes to 0 from this point on
G0 Z200.000 ; Raise Z to remove probe
G21 ; Set units to millimeters
G90 ; Absolute positioning, just in case
G38.2 Z-400.000 F500 ; Probe Z from max Z height, in case it was homed
G92 Z14.000 ; Set Probe offset to 14mm, thickness of probe
G92 X0 Y0 ; Set X Y axes to 0 from this point on
G01 Z200.000 F500 ; Raise Z to remove probe
I probably would not raise Z to 200 from 14. Too time consuming and not needed just to remove the probe.
G0 is probably the correct code to lift Z (That’s what I use) but I see that you didn’t have a feed rate specified. F500 is pretty slow, and raising 186mm at 500mm/min takes something over 22 seconds, which is quite a long time for setup.
I lift mine by about 9mm, which is plenty to remove the probe. I also use a relative move for this.
You can optimize a little better with the G92 commands, there doesn’t need to be 2 of them in a row, you can set all 3 axes (G92 X0 Y0 Z14) though I would have set X and Y manually earlier, myself.
I use M400 commands to be sure that the machine has stopped moving before G92 commands. It should be fine with probe moves, but it’s a habit for me to explicitly wait for the machine to stop moving first.
So for me, that might look like this:
G21 ; Set units to millimeters (This is pretty safe to assume that it's already set for me.)
G90 ; Absolute positioning, just in case
G38.2 Z-400.000 F500 ; Probe Z from max Z height, in case it was homed
M400 ; Wait for movement to stop, to be certain
G92 X0.000 Y0.000 Z14.000 ; Set Probe offset to 14mm, thickness of probe
G91 ; relative moves
G0 Z10.000 F500 ; Raise Z to remove probe
G90 ; Absolute positioning again.
Hey Dan, how the hell do you then manage to remove the probe? I really need some space to put my hand below the router to remove the probe
Indeed, that seemed to be the issue! I did not include it at first, as it does work through the terminal without speed settings. I adapted my script, and now it works. Me happy ! Going to play some more with those speed settings to get used to it.
Could you be so kind to tell me why you would do that? I think i´m not yet at the point I understand the reasoning behind this.
Noted, and adapted in my script I also added a LCD message M117 to confirm where I am
edit: I was looking at the Marlin page “Linear Move”. Is there a minimum/maximum limit somewhere in Marlin on the feed rate mm/min?
It’s not terribly important, but in the event that I change configurations, a relative move will still work, where an absolute one might not. I use a touch plate that is quite thin, but if I were to change to a thick setup, it’s one more parameter that doesn’t need changing, or at least won’t hurt anything.
So say I give myself 10mm clearance, but now have a plate 15mm thick. In relative mode G0 Z10 will still lift the tool 10mm, where in absolute mode, it will try to plunge it 5mm into the touch plate. This will likely never be a problem but it’s something that I got into the habit of from 3D printer gcode where I lift the nozzle at the end of a print and don’t know how high my print will be.
There is a feed rate maximum, so even if commanded to go faster, it will limit the feed rate. It’s in Marlin’s configuration.h file.
So, I have been avoiding it for some time, but I think it´s time to do something with the vacuum system.
My idea is to hang a vacuum tube to the ceiling, so it can move around freely without being in my way. I would buy a cyclone filter and bucket, where I can hook up my vacuum cleaner.
If there´s some one with feedback related to this, please shout
I am thinking to buy this tube, it is 15 meter long so will cover my needed distance to the ceiling, and has a diameter of 32mm which is I believe enough to fit Ryan´s design on the X plate.
As far as my understanding goes, it´s all a fit, although I will probably need an adapter on the cyclone to fit the tubes.
The big question will be if my vacuum cleaner will be powerful enough:)
I´m still doubting, but will probably order it this weekend, so I feel like a little kid now
I am sure there will be many new chapters soon!
