Firmware Suggestions?

[Jason von Nieda]

Hi all,

Thanks to the generosity of one of the list members, I now finally
have a physical machine on my desk to develop against. This will speed
things up immensely, and allow me to clean up little things here and
there that don't translate well from simulator to real world.

With that said, as I set things up this evening I find that our branch
of Grbl is severely lacking. It is based off of the original Grbl
firmware, which I believe was eventually abandoned and there are
several obviously problems.

So, I am asking for advice. What would be a good starting point for
our firmware? I've been reading through some of the Reprap firmware
and there are a bunch, and there are probably a lot that I am not
aware of.

Here is a basic list of requirements:
* 4 axes - although we can hack a 4th in to a 3 axis system if we have
to. We need X, Y, Z, and C. For reference, we hacked C axis support
into our branch of Grbl and it's treated as simply another linear
axis.
* Real time communication - i.e. not a simple g-code file interpreter.
We need to be able to send commands and wait for them to finish before
proceeding.
* Per command speed setting.
* Acceleration. Doesn't have to be fancy, but it must work.
* Stable.
* Minimum of somewhere around 10k steps per second.

And some nice to haves:
* Arduino compatible.
* Runtime configurable.
* Some type of home switch support. We'll hack it in if we have to.

Stuff we specifically don't care about:
* G-code: I don't care what protocol it uses if it meets the above requirements.
* Language: Don't really care what it's written in. It would be nice
if it's not spaghetti code though :)
* Compatibility with other systems: Chances are we're going to be
making OpenPnP specific changes anyway.

So, does anyone have any recommendations? I'm more interested in
actual experience with particular software rather than random links.

Thanks,
Jason

[Karl Backström]

Great progress Jason!

For my shapeoko hardware I took the newest edge version of grbl (0.8a I think) and hacked in limits support, I had to do some hacking to get it to work.

Next on my list is to hack support for a 4th axis to it.

/Karl

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To post to this group, send email to ope...@googlegroups.com.
To unsubscribe from this group, send email to openpnp+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Blog: http://www.akafugu.jp/blog/
Twitter: akafuguJP
Facebook: http://www.facebook.com/akafugu

[Arthur Wolf]

HI !

I'm obviously biased in favor of it, because I wrote it, but I really wouldn't understand you not using Smoothie :)

It has all of the features you mention ( and much more ).

About Gcode, there are many things you can do with smoothie :
1. Use gcode, simply reduce the queue size to 1.
2. Use gcode, create a new gcode that waits for the queue to be empty before answering ok ( my favorite, because it can be useful to other machines too, and doesn't change the rest of the protocol )
3. Use gcode, make new gcodes that do the move and then wait to be done before answering ok.

I think the main advantage of Smoothie over other choices you can make, is that it's built from the ground up to make adding new stuff to it as simple as possible.
This means that you can add any feature to it, without having to touch/undertand any of it's inner workings : simply create a new module, plug into events, do stuff, that's it. http://smoothieware.org/moduleexample

Now what's cool about that, is that many projects/uses can then share the same firmware. Atm, Smoothie knows how to laser, 3D print, cnc mill. You would share a common code base with all of that. When other ppl that don't use openpnp, but use Smoothie, make ameliorations to the core, you'd profit from it ( and there are a lot lately, even though we don't even have a board yet ).

The board is coming mid-august : http://smoothieware.org/smoothieboard

It also has lots of neat features, I always forget a lot, but : It has composite usb Serial and Mass storage ( simply drag and drop gcode files to it and it plays them, edit the config file directly on the board etc ... ), text file based config, play/pause, endstops ( in the unstable stepper branch, stable soon ), and .. yeah I always forget everything ...

And of course there's the fact that it runs of a 120Mhz 32bits chip, to compare to the arduinos.

We also will soon have delta robot support, and it has built in abstractions that make coding any non-cartesian arm solution a snap anyway.

It runs of the LPC1769 but there are ongoing ports to SAM3U and STM32F4.

But eh I coded it, so I'm not the most objective person.
Maybe there are other smoothians around here that can give their opinion, I would strongly suspect so :)

I love the project, and I'm always amazed by how fast you make progress.
If you have any question about smoothie, I'm around.

Cheers !

2012/7/22 Jason von Nieda <ja...@vonnieda.org>

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To post to this group, send email to ope...@googlegroups.com.
To unsubscribe from this group, send email to openpnp+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Courage et bonne humeur.

[David Armstrong]

Jason,
 
Arh! i notice Arthur has beaten me too it .. i'd go along with smoothie , although i'm probably biased 
iv'e come to the conclusion over the last few years that for serious motion control , the arduino is just not up for the job
although nice as it is ...
 
iv'e moved more towards the Cortex M3 for development , i feel this would give the project more room for the future
the arduino just being too restrictive .
 
i am also looking at using a mini 2440 with a touch screen as a development tool ( or similar ) using linux as a base OS
this direction would give a higher end controller including machine vision as a dedicated machine without having to use an additional pc
and have the ability to network .. this would incorporate openpnp and the controller into one intergrated pcb .
 
so yes lets see what opinion others have and incorporate the direction of development further
so i see a multiple option an entry level user and a more proffesional one .. down to cost of course but not prohibitive ..
 
Dave  
 

> Date: Sat, 21 Jul 2012 23:16:39 -0700
> Subject: [OpenPnP] Firmware Suggestions?
> From: ja...@vonnieda.org
> To: ope...@googlegroups.com

[Richard Spelling]

I would highly recommend Tonokip Sprinter firmware.

I plan on using it for the laser cutter I'm building.

It meets all your specs, and then some.

In fact, I don't think that it will require very much modification to
build a PNP machine with it at all.

--
Visit my online store for solar electronics: http://www.spellingbusiness.com
------------------------------------------------------------------------------
NOT sent from a Blackberry. Sent from a free hand-me-down PC running
free open source Ubuntu Linux... :-P

[Richard Spelling]

addressing your requirement list.

Tonokip Sprinter:
-4 axis, no hacking required. the RAMPS board I use for the 3d printer
has the pins for 5 axis, and sprinter is easy to modify to use the 5th
if needed. (int he case of reprap it's "E" (extruder) axis, but that's
just the designation)

-arduino/sprinter does all the real time communications with the motors.
you can stream gcode to the arduino over the usb port. Since motion is
controlled by the arduino, if your computer pauses or something, it just
waits for you as soon as it has finished the last gcode command. This
means you can read your camera and figure out the adjustment and simply
stream to the USB port the gcode to move the head to the adjusted
alignment position.

every gcode line can have a feed rate. I think some even have two. i.e,
move to XY at speed F1 and have extruder turn at speed F2


- well field tested, I've been using it for a year+. Zero problems with
the firmware. thousands of others in use.

- it's not called "sprinter" for nothing... I had to slow it down as the
small high speed moves were shaking my reprap apart... :-) I'm using 16
micro-stepping, I don't know that that is in steps per second, but the
pitch of the motors is almost ultra sonic.

Arduino Mega has lots of extra pins available, and is fairly inexpensive.

Written in "C" and Arduino IDE for modification.

On 07/22/2012 01:16 AM, Jason von Nieda wrote:

[David Armstrong]

Richard ,
 
looking through the sprinter now , yes i think it just about fits all the right key points
i'm going to build one up now and see if i can find any pertinant points that need addressing
for our specific use , but overall i dont see anything major missing .
 
 
Dave
 

> Date: Sun, 22 Jul 2012 10:03:32 -0500
> From: r...@richardspelling.com
> To: ope...@googlegroups.com
> Subject: Re: [OpenPnP] Firmware Suggestions?

[Jason von Nieda]

Thanks for the suggestions everyone! Sprinter seems to be the clear
leader here. I had several off list recommendations for it as well.

So, with that said, my plan for today is to try the newest version of
Grbl first. That is more out of personal curiosity than anything. I
want to see if the bugs I am seeing were ever fixed. Even if it's
working well it still leaves me with limitations that it sounds like
Sprinter doesn't have.

So I will try Sprinter next, although it sounds like I might need to
go buy a Arduino Mega first. I have a Duemilanove, currently. Luckily
there are a few places in town I can go to get a Mega in short order
:)

Finally, since several people recommended Smoothie, I wanted to
address that: The Smoothie project looks very impressive. It seems
well organized, well thought out and very well designed. If I had a
compatible board handy I would probably jump right on it, but I don't
have one or a way of getting one today so it will need to wait a few
days. Unless it's an easy port to Maple? Does anyone know? I do have a
Maple handy.

I'll report back soon!

Thanks,
Jason

[Arthur Wolf]

Finally, since several people recommended Smoothie, I wanted to
address that: The Smoothie project looks very impressive. It seems
well organized, well thought out and very well designed. If I had a
compatible board handy I would probably jump right on it, but I don't
have one or a way of getting one today so it will need to wait a few
days. Unless it's an easy port to Maple? Does anyone know? I do have a
Maple handy.

There is an ongoing port to STM32F1 ( maple ), STM32F4 too ( the $10 discovery board ).
Smoothie runs out of the box on the €20 LPCXpresso1769, with complete documentation on how to set it up here :  http://smoothieware.org/smoothie-on-a-breadboard

We'll have smoothieboards for sale mid-august hopefully, there's one free for you as for several other openhardware project ppl.

Cheers !

[Jason von Nieda]

Thanks Arthur! I'll be picking up an LPC board sometime in the next
few days so I can try Smoothie out. The SmoothieBoard sounds
interesting, and could end up being a good choice for OpenPnP but I
need to do a lot more learning and experimentation with stepper
strength first. As it stands right now, I am using 4.2 amp steppers at
36v, so the Allegro drivers aren't going to do the trick. That may be
overkill, though. Once the actual hardware design gets nailed down a
bit I can see what is actually needed for the job.

Thanks,
Jason

[Arthur Wolf]

2012/7/22 Jason von Nieda <ja...@vonnieda.org>

Thanks Arthur! I'll be picking up an LPC board sometime in the next

few days so I can try Smoothie out. The SmoothieBoard sounds
interesting, and could end up being a good choice for OpenPnP but I
need to do a lot more learning and experimentation with stepper
strength first. As it stands right now, I am using 4.2 amp steppers at
36v, so the Allegro drivers aren't going to do the trick. That may be
overkill, though. Once the actual hardware design gets nailed down a
bit I can see what is actually needed for the job.

Smoothieboard can drive 1.9A NEMA23 steppers at 30v ( like what pololus theorically can, except it doesn't burn when you try ). That has quite a lot of punch, and I think would be sufficient for a pick and place.
But if it's not, there will also be a version of smoothieboard *without* the stepper drivers on it, cheaper, and you can plug any stepper driver you want into that.
Possible options include the cheap CW-5045s, or anything using A4989s like stomp : https://github.com/kliment/Stomp/

[Richard Spelling]

I'm getting 800ipm on Zippy with 2A steppers. I think 4.2A is way
overkill, unless you are trying to move a 1000lb milling machine.

I have stalled out the steppers on Zippy when I ran (4mm diameter) pin
into the side of something accidentally. Didn't bend the pin. 2A is a good
number compromise.

Also, then you can use the pololu stepper boards....

I highly recommend the RAMPS board as well. It concentrates all the wiring
in one tight package. I will be using it on future bots.

--
Visit my online store for solar electronics: http://www.spellingbusiness.com
------------------------------------------------------------------------------

"If at first the idea is not absurd, then there is no hope for it.”-
Albert Einstein

[Jason von Nieda]

I think you are probably right. My CNC background is, in fact, with
milling machines so I am used to larger motors. Either way, when I
settle on a hardware design I'll do the necessary math and see what
the actual hard requirements are. It would be great if it's feasible
to use a cheaper / smaller board and still maintain the speeds I want.

Richard, what firmware are you using with Zippy?

Jason

[Richard Spelling]

Zippy is a converted Zenbot.
http://www.zenbotcnc.com/

It uses this driver board:
http://www.easy-cnc.com/4axisdriver.html

The controller is a IBM Thinkpad T40 running EMC2 and Ubuntu. One of the
few laptops you can get that still has a parallel port.

My software just generates straight gcode which I run blindly on the
machine. No camera feedback.

FWIW, I finished the conversion to all feeders last weekend. Already ran
36 boards on it with feeders. Much faster, smoother, and fewer problems.
The occasional part will jump out, but I'm sure this will fix itself as
the 3d printed tape guides wear smooth.

[Nuri Erginer]

http://store.gnexlab.com/category.php?id_category=5

Take a look at that site also

[mcgyvr]

Figures.. Just got my mega and got the openpnp grbl loaded onto it..

Well hopefully Jason can get this code coming out faster and actually
working now.. I've been sitting here with the hardware 100% complete
and just waiting for the firmware to run it..

> >>>> On Sun, Jul 22, 2012 at 9:47 AM, Arthur Wolf <wolf.art...@gmail.com>

> >>>>> For more options, visithttps://groups.google.com/groups/opt_out.

>
> >>>> --
> >>>> You received this message because you are subscribed to the Google
> >>>> Groups
> >>>> "OpenPnP" group.
> >>>> To post to this group, send email to ope...@googlegroups.com.
> >>>> To unsubscribe from this group, send email to
> >>>> openpnp+u...@googlegroups.com.

> >>>> For more options, visithttps://groups.google.com/groups/opt_out.

>
> >>> --
> >>> Visit my online store for solar electronics:
> >>>http://www.spellingbusiness.com
> >>> ------------------------------------------------------------------------------
> >>> "If at first the idea is not absurd, then there is no hope for it.”-
> >>> Albert Einstein
>
> >>> --
> >>> You received this message because you are subscribed to the Google
> >>> Groups "OpenPnP" group.
> >>> To post to this group, send email to ope...@googlegroups.com.
> >>> To unsubscribe from this group, send email to
> >>> openpnp+u...@googlegroups.com.

> >>> For more options, visithttps://groups.google.com/groups/opt_out.

>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "OpenPnP" group.
> >> To post to this group, send email to ope...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> openpnp+u...@googlegroups.com.

> >> For more options, visithttps://groups.google.com/groups/opt_out.

[Jason von Nieda]

I wouldn't worry. My focus today is on Arduino / AVR since that is
what I own currently and am most familiar with.

If you have complete hardware there is nothing stopping you from
running OpenPnP. My setup was having trouble with Grbl, but others are
using it. If you want to get your machine up and running I'd say just
go ahead and start and ask questions as you go.

Jason

[you...@ciciora.com]

Please consider TinyG
(http://www.synthetos.com/wiki/index.php?title=Projects:TinyG). While
not
arduino, it uses an atmel XMega chip. As far as I know, it's the only
one
in it's class that has Jerk control. I think this is a good thing for
home-brew pick and place, as usually these machines are not as ridgid
as
commercial machines.

- Steven Ciciora

[Bryan]

Jason ... it seems likely that (even the small amount) of extra code you added to Grbl for all the extra needed runtime command might have caused the little Arduino to run out of RAM. I'm fuzzy on the details now, but I remember we had issues with insufficient RAM when I did the original port and added the forth axis. We gained back a bunch by eliminating the look-ahead buffer -- but perhaps not enough. Random bugs would be the order of the day in this case, for sure.

For my vote -- Smoothie. I wanted to use it right from the start. But the source code hadn't quite been released at the time. Nice to see it turning into a fully fledge public project. Yay \o/

Actually, my vote is as much running on a 32-bit ARM chip, as anything else. Apart from being much faster, it has one very important feature that none of the AVR based 'dunios do -- DMA. That may or may not seem like an issue for OpenPnP requirements today. However, if my experience with the gruvin9x RC controller board is anything to go by, you could well end up regretting the use of an old-school 8-bit MCU with no DMA, later on. These project have a way of attracting users and ideas for features you could never of dreamed of yourself! :-P

Of course for now, whatever works will be the order of the day. Ai ai captain! All ahead full! :P

Bryan.

[Jason von Nieda]

Some explanation on that:

I went ahead and upgraded to the latest Grbl and it did fix the
specific problem I was having, which was a kind of ultra-slow stepping
at the end of a move. The things that caused me to look elsewhere
were: No (decent) homing support, would have to re-port the C axis in,
poor pin configuration.

So far, Sprinter seems like a winner. I have a few small gripes with
it but I will either submit patches or ask Kliment to help out.

I fully support the idea of using Smoothie. It looks great. And that
brings me to a point I really want to harp on: OpenPnP is very easy to
extend! I ported the GrblDriver to a SprinterDriver over the course of
today while I had time and I would say it has no more than 1 hour of
development in it. It will be just as easy to write a SmoothieDriver
when I have the hardware in my hands. I don't want anyone to feel like
they can't use the hardware of their choosing - and I think the Driver
model that OpenPnP uses makes that a very trivial concern.

As of right now I have my machine working with Sprinter and have been
working on adding proper homing support to the OpenPnP code. That all
seems to be working now, so I am moving on to improving how jogging is
handled in the GUI. Right now it's awful; one of those things that's
not very obvious in the simulator but very obvious on real hardware.

I will also say that so far I am enamored with the Arduino Mega2560.
All those extra pins really make deciding how to lay things out much
easier.

And finally, for anyone curious, here is the new OpenPnP development rig! :)

https://twitter.com/vonnieda/status/227280610622853120/photo/1/large

Jason

[Bryan]

On 23 July 2012 17:57, Jason von Nieda <ja...@vonnieda.org> wrote:

Some explanation on that:

I went ahead and upgraded to the latest Grbl and it did fix the
specific problem I was having, which was a kind of ultra-slow stepping
at the end of a move.

Noted. Thanks. I had that silly slow steps at the end of runs problem initially. It was fixed by putting a zero or two on the end of one of the default parameters, to bring it within the same sort of range of the higher step-per-minute number etc. But hey -- if sprinter is working well out the box then yippie! I'll go google it shortly. I'm also going to have a look at the smoothie for Maple version, as it were -- some time.

Arduino mega ... yeah -- we use the ATmega2560 (like the Arduino Mega) on our RC controller. 100 pins. yummie. :-)

Beafy worm drives! You'll be able to punch holes in PCBs -- or crush piles of junked components for recycle metals storage. Bonus! :-P Me jealous. So cool that have a machine now. THANK YOU whoever made that happen!

Meanwhile, I am edging slowly closer to getting my own hardware together. It'll be some weeks yet though. Other than funding, the main hold up is simply having had precisely zero experience with anything like this before -- and many failed attempts at building mechanical things in the past. Paralysis by analysis and all that. But I'm going to have to bite a bullet some time soon me thinks. OpenPnP seems so close to be ready for use already! Amazing.

Bryan.
 

[Bryan]

On 23 July 2012 08:29, you...@ciciora.com <you...@ciciora.com> wrote:

Please consider TinyG
(http://www.synthetos.com/wiki/index.php?title=Projects:TinyG).

...

Thanks Steven. I've not personally come across TinyG before, I don't think. Version 6 now, you say? Interesting!

I've just been reading about TinyG (link provided above.) It sounds really good (too) for our purposes Jason. XYZ ABC axes, with angular units for the latter, 3rd order jerk control, G28.1 homing and more.

It even has an (additional/optional to G-code) interface named after you Jason! :P ...

In addition to command line operation, TinyG implements a JSON interface. This gets pretty arcane, but is useful if you are writing a controller for TinyG. The JSON interface is really a REST interface that implements the objects and verbs in the system. Its different from what people normally think of as REST in that the transport is USB serial, not HTTP. ref: JSON commands

I wonder if that would make integration with OpenPnP even easier? I guess it would if you were to include low-leel parameter control GUI especially for TinyG, which would seem an overkill to me. But hey.

So many cool project out there these days -- and growing in number by the minute. Great time for a gadget man to be alive huh? :P

Bryan.

[Arthur Wolf]

++ for making openpnp easy to extend :)

Just wanted to add a little thing on smoothie.

It's been brought to my attention that I can be too enthusiastic or even pushy about it :)

So just to be clear : Smoothie is beta code, used by just two dozen ppl at this point.

It is far from being as mature as a Sprinter or a Marlin etc. Those have thousands of users, and a much longer history.

It also lacks some important features ( homing, some m/gcodes ), and while they are currently being coded, or on the urgent todo list, you will probably miss some things at one point or another.

Just to be clear.

Cheers !

[David Armstrong]

Jason,
 
whilst not trying to start a war over the different versions of the arduino code , as it seems to have sprouted
totaly out of control as far as the reprap is concerned , but i see it as a good point and bringing maturity etc
 
take a look at Marlin , it does seem to have a few extra points worth looking at
like the read ahead , and LCD display etc , although i fully admit it is a clone of sprinter also
with extras .
 
but over all i totaly agree sprinter does seem to best cover everything as a base controller .
 
i should shortly have a test rig sorted here , so will be able to test in real time
 
Dave

 

> Date: Sun, 22 Jul 2012 22:57:19 -0700
> Subject: Re: [OpenPnP] Re: Firmware Suggestions?
> From: ja...@vonnieda.org
> To: ope...@googlegroups.com
>

[Jason von Nieda]

Read ahead is very important - I thought Sprinter actually had this.
If it doesn't, I'll be looking at Marlin or maybe seeing if that lies
in the future for Sprinter. I'm doing some work on making jogging
smoother in OpenPnP and I am pretty sure I will need read ahead
support in the firmware to make this happen.

[Richard Spelling]

Why is read ahead important?

[Jason von Nieda]

Currently in OpenPnP when you are jogging the axes to position
something you jog by an increment and OpenPnP just sends relative
movements to the machine. So, for instance, if you have 1mm selected
and you press Ctrl-Up Arrow the machine will send a movement from the
current position to the current position + 1mm in Y.

The problem with this is that it causes each jog operation to cause an
acceleration and deceleration. So, let's say you are trying to jog 3mm
and you hit the key three times, the machine will:
accel, move, decel, accel, move, decel, accel, move, decel.

It makes for very unpleasant jogging.

What I have been thinking I would do is as long as the user is
jogging, keep the firmware's buffer full of jog commands and then when
they let off the key we would clear the buffer.

I have not yet spent a lot of time on this, so perhaps someone can
suggest a better way.

Jason

[Richard Spelling]

I can see how that would make lining the camera up difficult.

emc2 has a "continuous" jog mode, where 3d printer doesn't (that I know of)

you hold the key down, and it moves at jog speed until you let the key up

I think this is what you are wanting. not sure how to do that on the
printer, but you could simulate it like you are saying, just sending a
stream of commands until the key is let up.

I know the 3d printer doesn't stop between gcode commands, so it has
"blending" of some sort.

Kliment will be able to answer this better than me I'm sure.

maybe google "continuous jogging" tonokip and/or sprinter firmware.

[Richard Spelling]

just take the jog speed setting and figure out how often you need to send
a "move 1mm" command to simulate continuous, and stream those to usb at
that speed while key is pressed, and Bob's your Uncle.

It won't stop between them, as it doesn't while printing, so blending will
make it continuous.

[Jason von Nieda]

Re: continuous jogging - yes, this is what I am looking for. Mach 3
has the same, and I love it. It's easy for these programs because they
are generating the steps, but OpenPnP is not.

On Tue, Jul 24, 2012 at 8:50 PM, Richard Spelling
<r...@richardspelling.com> wrote:
> just take the jog speed setting and figure out how often you need to send
> a "move 1mm" command to simulate continuous, and stream those to usb at
> that speed while key is pressed, and Bob's your Uncle.

Unfortunately taking the speed setting isn't as easy as it sounds.
While OpenPnP does send the feed speed, it does not have any control
over acceleration, deceleration, intra-move delays, etc so it has no
idea how long moving 1mm will actually take. One of the downsides of
having an abstract machine driver model vs. being closely coupled with
the machine.

>
> It won't stop between them, as it doesn't while printing, so blending will
> make it continuous.

This is a good point, and something I hadn't thought of. Of course it
doesn't start and stop between every movement while printing... at
least I don't think it does. So why is it stopping between moves when
I am streaming commands faster that it is processing them? It seems
like it should also smoothly move between commands.

I thought that it not having look ahead was the reason for this. My
reasoning being that without look ahead it would not know the velocity
of the next movement, and therefore could not just continue moving.

I'll have to look into this further.

Jason

[Richard Spelling]

that makes sense.

a tradeoff. you don't need a real time kernel to run the machine, but
jogging is a bit more complicated.

hmmmm

repsnapper (3d printer software I use mainly as my machine controller)
gets around this by having -100, -10, -1, +1, +10, +100 buttons. perhaps
something similar or a bit more sophisticated?

what comes to mind is a square section of screen around a pixel.

a bit away from the center is .1mm, a bit further away is 1mm further yet
is 10mm, etc,

so where you click on the square with the mouse tell it how far to jog in
both X and Y.

call it a "jog pad"

just a thought.

[Kliment Yanev]

On 07/25/2012 02:55 AM, Jason von Nieda wrote:
> Read ahead is very important - I thought Sprinter actually had this.
> If it doesn't, I'll be looking at Marlin or maybe seeing if that lies
> in the future for Sprinter. I'm doing some work on making jogging
> smoother in OpenPnP and I am pretty sure I will need read ahead
> support in the firmware to make this happen.
>

Yes, Sprinter has this, midopple ported it over from Marlin, and Marlin
picked it up from grbl. :)

[David Armstrong]

 
Jason ,
 
i am recieving an error from git , i'm presuming it's thrown a fit somewhere
anyone else have a problem ?
 
Cloning into 'C:\openpnp2\openpnp'...

fatal: https://google.com/p/openpnp/info/refs not valid: is this a git repository?
git did not exit cleanly (exit code 128)
 
(notice the /info/refs )
 
also for interest i have set up a IRC channel for openpnp on freenode #openpnp
 
 
Dave

[Jason von Nieda]

> repsnapper (3d printer software I use mainly as my machine controller)
> gets around this by having -100, -10, -1, +1, +10, +100 buttons. perhaps
> something similar or a bit more sophisticated?
>
> what comes to mind is a square section of screen around a pixel.
>
> a bit away from the center is .1mm, a bit further away is 1mm further yet
> is 10mm, etc,
>
> so where you click on the square with the mouse tell it how far to jog in
> both X and Y.
>
> call it a "jog pad"
>
> just a thought.

A great thought! I really like this idea. Especially since I have
tried to design OpenPnP with the idea of being controlled from a touch
screen in mind. I'll add this to the list :)

[Jason von Nieda]

David, did you get this resolved? I think it was just a hiccup at Google.

Jason

[Jason von Nieda]

Also: re the IRC channel. Thanks for setting that up! I'll be hanging
around in there.

Jason

[Jason von Nieda]

Thanks Kliment, I will look further into why I wasn't seeing the
behavior I expected.

Jason

[David Armstrong]

yes it resolved it's self Jason
 
dave
 

> Date: Wed, 25 Jul 2012 21:38:20 -0700
> Subject: Re: [OpenPnP] git error
> From: ja...@vonnieda.org
> To: ope...@googlegroups.com

[Kliment Yanev]

On 07/26/2012 04:15 AM, Jason von Nieda wrote:
>> repsnapper (3d printer software I use mainly as my machine controller)
>> gets around this by having -100, -10, -1, +1, +10, +100 buttons. perhaps
>> something similar or a bit more sophisticated?
>>
>> what comes to mind is a square section of screen around a pixel.
>>
>> a bit away from the center is .1mm, a bit further away is 1mm further yet
>> is 10mm, etc,
>>
>> so where you click on the square with the mouse tell it how far to jog in
>> both X and Y.
>>
>> call it a "jog pad"

Have a look at how we implemented this in Pronterface. It only does one
direction at a time, but the idea's there.

>>>>>> "If at first the idea is not absurd, then there is no hope for it.�-

>>>>>> Albert Einstein
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "OpenPnP" group.
>>>>>> To post to this group, send email to ope...@googlegroups.com.
>>>>>> To unsubscribe from this group, send email to
>>>>>> openpnp+u...@googlegroups.com.
>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>
>>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups
>>>>> "OpenPnP" group.
>>>>> To post to this group, send email to ope...@googlegroups.com.
>>>>> To unsubscribe from this group, send email to
>>>>> openpnp+u...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Visit my online store for solar electronics:
>>>> http://www.spellingbusiness.com
>>>> ------------------------------------------------------------------------------

>>>> "If at first the idea is not absurd, then there is no hope for it.�-

>>>> Albert Einstein
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "OpenPnP" group.
>>>> To post to this group, send email to ope...@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> openpnp+u...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "OpenPnP" group.
>>> To post to this group, send email to ope...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> openpnp+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>>
>>
>> --
>> Visit my online store for solar electronics: http://www.spellingbusiness.com
>> ------------------------------------------------------------------------------

>> "If at first the idea is not absurd, then there is no hope for it.�-