- February 17, 2017 at 12:29 am #27758
As my parts arrived, and I am now building my machine, I need to decide, how I setup the system in my shop. Until now, I don’t completely understand, what happens after I generate the gcode.
What I know: I build stuff in CAD (I am doing this for years for my 3d printer now). I export that as DXF (I’ve done that already, to get stuff milled by a friend). Than I open a CAM Software, setup how each line is cut and generate gcode out of it (what is more or less, what a slicer does for 3d printing, just with more manual work).
And than, I see the use of repetier on the page, that seems to be used only a. control the router manually and b. send the gcode to the arduino to be processed.
Do I have to do that with repetier, or can this also be done directly from Estlcam and/or Fusion 360. If so, are that configuration-examples for those tools?
JensFebruary 17, 2017 at 7:33 am #27779
Sounds like you’re way ahead of the curve. The CAD/CAM stuff took me a while to figure out.
If you have the LCD, then you can put the .gcode file on the SD, and print it from the menu. That’s the best way to get started, IMO.
You can also use printrun/pronterface, I think. I haven’t tried that myself. I’m not sure why you’d prefer that over repetier though.
https://www.vicious1.com/repetier-host/February 17, 2017 at 8:20 am #27784
For what it is worth, Repetier “drips” the gcode to your machine, meaning the entire file is not sent all at once before cutting begins. Similar to streaming video. You may or may not find this useful. The “drip” term is something you may hear among CNC machinists who have a network of machines.
Jogging the machine with the LCD when connected to Repetier does not update the coordinates back to Repetier, you have to update with a G92. However, the LCD is updated when jogging with Repetier.
I often use both Repetier and the LCD controller during a cycle run. Running directly from the LCD does isolate the machine from the computer though. So if the PC crashes, your machine won’t.February 17, 2017 at 2:56 pm #27820
Have done my first run with repetier. Drew the vicious logo onto paper with a pen.
I than drew 2 simple pieces in Fusion 360, that should fit together, used Estlcam, because i dont understand CAM in fusion yet, to generate gcode and than milled it with Repetier into 3mm Depron. Yay! It works, but i don’t like the workflow, bit thats mainly because my only windows computer is 2 floors up from my shop in the basement.February 17, 2017 at 3:14 pm #27823
repetier works in Linux. 🙂February 17, 2017 at 10:51 pm #27838
Yes and on my macbook too, but I like the way Estlcam works, so I need a Windows PC around 😉February 18, 2017 at 8:39 am #27845
I haven’t tried the direct estlcam features, but I have ran estlcam in wine (playon Linux). There’s a post somewhere around here for that… Then there’s virtualization, but that’s a big hammer.February 18, 2017 at 1:29 pm #27860
I can connect my arduino to my linux machine in repetier host, but i get an “Communication Timeout” error all the time.February 18, 2017 at 1:40 pm #27862
Using what settings? Buad rate?February 18, 2017 at 2:01 pm #27863
Exactly those from your website, that is serial connection with 250000.
Ubuntu 16.04 with latest repetier host from their website.
Electronic is from you shop and is runng great with repetier host on my macbook. I just dont want to have my macbook in the dust all the time.
Thanks, JensFebruary 18, 2017 at 2:04 pm #27864
I am just making blind guesses in the dark here, but you might want to re-flash with a lower baud rate and try again. Some MAC’s require this as well for some reason.February 18, 2017 at 2:15 pm #27867
As I haven’t flashed it yet, because it was preflashed… What version do i use? The first on you marlin page? No changes other than the baut rate?
I am a little worried to brick the machine on the 2nd day, while it is running good with mac currently.
The computer is a really old atom cpu based machine (that i bought, because it is silent) around 2013. Maybe its to slot and i should try something faster?February 18, 2017 at 2:18 pm #27868
If you aren’t sure maybe you should hold off. It is a very easy process once you have done it..the first time is either very easy or a nightmare. Did you get an lcd screen to run it off of then you don’t need a computer at all?February 18, 2017 at 2:20 pm #27869
No, but maybe i should buy one. I didnt ordwr one, because my prusa has one, and i think the handling sucks 😉 i really dont like the axis controlling of it. I would sooo love a panel with direction buttons!
B16_32-LCD-112515 is the one that you flashed on it?February 18, 2017 at 2:23 pm #27870
I do the movements by hand, but if you are interested in that there are all kinds of controllers you can hook up, even game pads.February 18, 2017 at 2:26 pm #27872
You just disable the motors and move the rods b hand?February 18, 2017 at 2:28 pm #27873
Yup, the steppers are off by default. Better yet, move them when it is off then power it on, zero and position set.February 18, 2017 at 11:08 pm #27881
Went down to 57600 and now they are talking. Thanks for the hint!February 19, 2017 at 10:12 am #27907
That might be a little low, but if it works…
I have no idea why that is, you would think modern pc’s could use crazy buad rates. Crazy, but glad it works.February 19, 2017 at 1:34 pm #27924
Machined some 6mm plywood this evening. Did feel the same as before, so everything is good. Thanks again for that great design of the machine and the support! You rock!February 19, 2017 at 1:39 pm #27926
Awesome, good to know for sure. one of these days I ‘ll have to see how low that can actually go.February 19, 2017 at 9:20 pm #27966
Take a look at an average gcode file to see it’s size in bytes and multiply by 10. Then look at the estimated time for the project, convert to seconds. Divide the size by time to get bps. Fudge a bunch to allow for overhead, but I’m going to guess it’ll be 9600bps or less.February 20, 2017 at 7:39 am #28006
250k isn’t one of the “standard” baud rates, so some linux libraries (pyserial, I think) doesn’t support it. It’s not a problem with speed, just that particular number. 115200 works fine. In 3D printing, I’ve heard people blame those little warts on the outside of prints on slow USB/Serial connections, because the printer will pause for a very small moment, enough to get some squeeze out.
@Bill, I bet that number gets a lot higher when you are doing 2.5D, because each move is about the same number of characters, but the moves are way smaller. If you were cutting out a realistic octopus or something, I bet it could approach that limit.February 20, 2017 at 8:20 am #28013
Wow, so is there some way to measure this? Or I guess you’re right something with a bunch of long straight moves uses almost no data, but if it was curved on all three axis it would be making some very tiny steps…like when you pause a 3d printer. I always try and pause on a curve so I know it will drain its buffer right there, whereas during infill it could keep printing for a while.
Any idea what the buad rate is between the lcd and the ramps?February 20, 2017 at 9:05 am #28019
I’m looking at some of my generated gcode from estlcam (from the MP3DP, which is pretty simple, most of the time) and it looks pretty consistent at 4 decimal places, so maybe 40 characters for the worst X, Y, Z gcode move.
40Bytes/command * 10bits/Byte / (115200 bits/second) = 3.5ms/command
At a speed of 100mm/s, then you could have a resolution of:
100mm/s * 0.0035s/command = 0.35mm/command
The trouble with this estimate (well, there are many, it’s a great simplification) is that the resolution isn’t really under our control, so even if you’re fine with 0.35mm per command, estlcam might be doing 0.0001mm/command, in which case, the speed will drop significantly. The parts of a 2.5D that were really hogging out material would be in lines, so maybe not a big deal. That helical cutting might be a problem. Another point is that Marlin is going to be doing it’s acceleration limiting too, including on curves, so that might also be limiting it to the point where the baud rate doesn’t matter.
If I were going to try and figure out what speed was needed for a particular gcode file, I’d probably write a script that would essentially simulate the gcode moves, measuring the baud rate needed. But that would also be a poor estimation.
I wonder how hard it would be to get the current speed and current buffer size from Marlin. I keep wondering what speed the tool is actually moving, after all its acceleration limiting, and also knowing the size of the buffer would be pretty useful, I think. Isn’t there a way to customize the status message that it spits out periodically?
w.r.t. the LCD, I have no idea. It’s not using UART/Serial, is it? I thought it was using SPI or something. Might be a good question for some Marlin user group. I also thought the SD card was basically being connected directly to the Marlin, so it wouldn’t depend on the speed to the display, but the speed the Marlin can read the SD card.February 20, 2017 at 9:39 am #28027
If the serial is set too low the tool just pauses between moves, the computer will have no problem with keeping up. If the serial is set too fast for the computer to keep up with, the computer might miss a pause handshake an keep dumping characters that the Arduino ignores. I’m running 250000 on a 12 year old laptop (P4 with 1G ram) running Windows 10 and haven’t seen any indication of dropped characters, but I haven’t tried anything complex yet.
You must be logged in to reply to this topic.