ose / cnc-torch-table-ose Goto Github PK

We're using 3 not-very-stably mounted mechanical switches. The implications of poor homing sensors are that we can't resume a job using home as a way to get back to precisely where we were. Also we may not line up perfectly with the edge of the material.

I suspect this isn't a problem for GVCS tubes and plates. We should do some testing to learn this before spending time improving the sensors.

If we need to swap sensors, we have 3 optical sensor kits with the extra torch table / 3d printing parts which can be easily interfaces with RAMPS.

Once I get some known working gcode, I'll put it here for use as a test file.

See http://opensourceecology.org/wiki/GcodeCommunications

It seems to think it's at 0, 0, 0 in whatever position it starts up at. It also seems not to allow motion into negative x, y, and z or beyond about 220 on x and y. Figure that shit out!

Done!

I think the behavior built in the the firmware is that they'll stop the motors if hit.

It needs to spit out gcode that our firmware understands for the real instructions. If there's some extra stuff and the firmware is smart enough to skip over them, that'd be ok too.

List list of what marlin supports is at https://github.com/ErikZalm/Marlin/tree/Marlin_v1

We should not tackle this until we have a reliable solution to running hand written gcode. See #15 .

See http://opensourceecology.org/wiki/CNC_Torch_Table_2/Control_Overview#Software

Make sure the head lifts up between them.

It seems the system doesn't handle small or slow movements well. The motors start buzzing. This doesn't happen every time but is easy to trigger by making a small movement in Printrun (0.1 or 1). Bigger movements work smoothly but then sometime do this at the end.

I think the big movements start out fast and slow down at the end at that's when this happens.

The controller may be trying to feed them too little current or in some way underpowering them for the small/slow move but they wind up not being to move at all.

Another hypothesis is that there are areas of movement with higher friction and if the motors happen to be trying to make a tiny move with no momentum over those areas, they stall.

When this happens, I click stop motors in Printrun and it stops.

Two obvious things to try are:

• Increase current limit - http://www.indigent-networks.com/pololu-drivers-current-limit-configuration/
• Calibrate step size (less likely to help but needs to be done anyway) - #4

See if anything in the toolchain can deal with this for us. If not, check out http://opensourceecology.org/wiki/DXF_to_G-code_Conversion_Tutorial#Piercing

The "torch" should move back and forth while making an initial "pierce". For the circle, I think it should make the pieces inside the circle. I'm not sure if it should pierce the rectangle inside or on one edge. We want it to make the pierce in a part of the metal we won't use. I wonder how the piercing code knows what that is... There's a conversation at https://groups.google.com/forum/#!msg/dxf2gcode-dev/6ZnNcX3O5i4/d-3NeBfHpbUJ about integrating this functionality into dxf2gcode which would be great for ease of use and gives us a gui where maybe we could click where we want the pierce to be.

Make sure each motor moved properly when using the RAMPS test code.

http://opensourceecology.org/wiki/DXF_to_G-code_Conversion_Tutorial

Some of the screws don't have springs around them.

The springs that pull the gear teeth into the racks should be tighter.

The gears need to be carefully aligned with the racks for even wear.

http://www.indigent-networks.com/pololu-drivers-current-limit-configuration/

Input:
https://scrumy.com/torchtable
https://scrumy.com/samthetechie

Output:
More of these: https://github.com/OSE/CNC-Torch-Table-OSE/issues/new !

The border looks good but at least one of the holes was messed up the last time I ran it. I was doing it one instruction at a time in printrun.

It's possible the box I taped the paper to was moving so first step is to try clamping that down and rerunning it.

http://reprap.org/wiki/Triffid_Hunter's_Calibration_Guide

The table at FeF is wider at one end than the other. It needs to be straightened out and set to width so that the side rollers are touching or very close to the rails. Marcin can show you what this means.

Use endstops for homing. Home each long axis motor separately in case one slips and they get out of sync.

Depends on #10

While I'm at true value, see if they have extra bearings and any other parts for those damn motor mounts.

Do any needed configuration.

Grbl looks sweet but doesn't support RAMPS out of the box and we're going for simple for the moment.

We may need more powerful stepper drivers to enable faster movement.

See http://opensourceecology.org/wiki/Stepper_Motor_Driver

Hi there,

what's the status of this project? I'm interested in FLOSS driver/controller for CNC and would be nice to have more info.

Do you still have plans to work upon the Lasersaur controller? Any result to share?

Many thanks!