My answer is: what accuracy can I expect? Ideally accuracy below 0.1 mm (what the human eye can see, but that demand is probably insane) but I would be pleased if it was no more than 0.5 mm - am planing to use multiple colors, so after one round of drawing I plan to change the color and start again (there goes the accuracy:-) ).

What I would like is the following:

• I want to be able to use real paint when reproducing a computer generated artwork and I would like to use different layers of paint, hence the accuracy. (I am planning to make my own paint markers, but this is the wrong forum for that)
• I suspect that my files are going to be rather on the big side because they will have lots of details. Think 10 to 20mb per color - about 250.000 vector points or more. (will probably use a program called vectoraster that converts images to black and white rastered eps files) And yes, I am aware that each round of drawing might take 10 hours or longer.
• I want to start small, A3 sized (17"*11") or maybe A2 (22"*17") and then perhaps go bigger - especially in the length (several meters) - so being able to reuse the components would be awesome.
• And of course, I am not rich, I work a shitty payed job a couple a days a week, make art on the side, so it should not cost too much :-)

So if there is any information anyone can give me, I would be happy - but you are of course also free to tell me that I am insane/ have to wait a couple of more years/ or that it is only doable if you invest like 10K and up and then maybe.

1. *step_output_reg[X_AXIS] sets the pin high/low for a step in the X axis. For linear and arc moves, there are two different routines for setting the pin high. And this will set the direction for movement.
fastDigitalWrite(direction_output_reg[i], direction_bitmask[i], !current_move_ptr->direction[i]);

0=x-axis, 1=y-axis, 2=z-axis

Again, it is implemented in two different locations for arc vs linear.

2. enable_steppers() and disable_steppers().
3. This portion is what constitutes a completed move:
if ( move_finished )

1.Variables for targeted X,Y and Z Coordinates.
2.The variable for drive enable/disable.
3.Where to respond with a moveComplete=true.

I could post back my code mods if I get it going.
Thanks in advance.

Just found this : http://www.thingiverse.com/thing:14980
It's a gcode viewer, opensource, make in processing, with 3D etc …
Do you think you'd have a hard time integrating this into GRemote, to get something like a "preview" button ?

The new features include:

• jogging in both absolute and relative mode (using gcode parser and position tracking)
• jog settings with jog size (decimal + fractional) and feed rate (incl. seek/rapid option)
• multi-axis/multi-size jogs using "accumulate" button (XYZ/DEL)
• arc movements given direction, radius, start & end angle (ARCS/INS)
• homing to preset limits, separate for XY and Z
• zero and memory set/goto per each axis (HOME,END)
• baud rate selector
• keyboard shortcuts: try j, h, a, +, -, X/x, Y/y, Z/z
• scaling feed rates with inch/mm switch
• modifications to support Grbl (though it /support/ is far from perfect)
• console for Windows (must run GRemote.bat instead of .exe)
• many modifications/improvements under the hood, including
  • waiting-for-response state support
  • code cleanup/rearrangement though there's still a lot of work on this

Screenshot:

You solution reset the timer and prevent overflow run, but as negative result, it doubles the step interval. Motors sounds "noisy" in the acceleration phase (and I suppose they skip steps).

I have a better solution. On non-modified firmware, add a line after

  if (inTimer1InterruptRoutine) return; inTimer1InterruptRoutine = true; // set very long time to disable timer1 interrupt until we are finished here OCR1A = 0xffff; 

and replace

  OCR1A = timer1LoadValue; 

  OCR1A = max(timer1LoadValue, TCNT1+10); 

If the calculation time is longer than the wanted step time, next step will follow just after calculations will be finished.

Another problem of current firmware is variable (and not-predicted) pulse duration. I have added a code to set precise and configurable pulse duration using second timer. It is to complicated to write differences here, but it is about 10 lines of code total.

As a result, I can now get smooth motion with feeds 300 and even 500 mm/min without skipping steps. It is 2 times better than before.

chuck

chuck

Thanks for the tip I'll go stare at the firmware code some more as none of the other things I've tried have worked.

chuck

https://sites.google.com/site/chuckscncarduino/

chuck

Thank you for developing Gremote. That's exactly the kind of software necessary for Contraptor success.
I installed it on Win XP and got the same results as Anydany: The interface shows only the com port dropdown and the Gcode entry line. However, I was able to set the proper com port and and I could send Gcode sucessfully through the entry line. The Gcode was executed and returned an "ok".

In doing so I found a deadlock situation that also exists in the original firmware:

the fragment below can (and did!) result in a deadlock when the G0 command finishes while the G90 command is being handled
G91
G00 X1.0
G90

Situation

The G00 step is running
The G90 command is received
This line locks the move_queue (process_string.pde)
// Lock move queue while adding new move
172 move_queue_lock_main = true;
The G0 step finishes
470 // If finished, start next move
471 if ( move_finished ) {
472
473 // Make sure queue not being modified by
474 // main routine and then advance
475 if (!move_queue_lock_main) advance_move_queue();
476
477 // If the queue is locked by the main routine, we can't hang about
478 // and wait for it as this would freeze up the whole system,
479 // so we just wait until the next time the interrupt routine
480 // is called and try again
481 }
The G90 command waits until the move is done (process_string.pde)
303 while (moving) {} // Do not try and do this while moving

Now the move_queue is locked, and moving is still true => deadlock

I fixed this situation by adding a 'move_queue_main_lock=false;' line before all 'while (moving) {}' lines

Jaap.

hope you can help to get it running… I have started your app under os x (old ppc) and I can only see the serial port dropdown, and the gcode entry line. all the other buttons are nonexistant in my UI. any idea? I haven't played around alot, just asking if you have a quick answer to that.

also when rebuilding the app from processing, I get no warnings. anyway, I am totaly newbie to processing… glad if you have an idea, thanks.

The data you have submitted contains following errors:

Guests and low-karma users are not allowed to publish links on this site.

chuck

Sorry, I guess I'm not allowed to put a link in.

chuck