Marlin branches for 3D printing and OpenPnP

[Neil Jansen]

All,

I've added some branches to the FirePick Delta Marlin fork, which is the motion controller software that runs on the EMC01 (or RAMPS 1.4 for the alpha folks that don't have one yet).  I've also done some housekeeping and cleaned up the other branches.

3D printing Functionality in branch: "Feature/3dprinting"
Works with RAMPS 1.4, J-Head, Wade's extruder, opto endstops, and heated bed.  You will still need to go through the config and configure your extruder and thermistor hotend, steps per mm, and all the other stuff that must be done if you're not buying a kit where someone did all that work for you.  This is one of the things that I really don't like about the current Marlin firmware, and it's one of the things that will be solved with our Modular Tool System in the EMC01 motion controller.  For example, the thermistor values and steps per mm will be stored in the tool, so you don't have to mess around with firmware at all once it's done.  In the meantime though, it will require a bit of patience and trial and error to get the config.h (and pins.h)  fully setup on your machine.  This is something that will come easier to the folks like Christian and myself that have built RepRap's from kits or from scratch. We can certainly try to help here if anyone has any questions, we're here to help.

Link: https://github.com/firepick-delta/marlin/tree/feature/3dprinting

Pick and place Functionality in branch: "Feature/Openpnp"
Works with RAMPS 1.4 and a hollow-shaft NEMA 8 motor.  No powered SMT feeders supported at the moment, or 3D printing functionality.  Right now, this is a separate branch, because OpenPnP needs the Z=0 to be somewhere in the middle of the work area.  That's because it uses zero as the "safe Z" level, and that can't be at the top or the bottom of the work area with this delta config.  I know how to get this fixed, but right now, it's all about baby steps and priorities.

Link: https://github.com/firepick-delta/Marlin/tree/feature/openpnp

Bleeding-edge development in branch: "Dev"
This branch will be devoted to getting the EMC01 fully supported with the modular tool system, and making the system 3D print and do Pick and Place, all without having to switch back and forth.  Consider this unstable until further notice.  If you have experience with the Marlin firmware and would like to help, please let me know, I'd be very grateful.

Link: https://github.com/firepick-delta/Marlin/tree/dev

Also note, if you happened to get your hands on an EMC01, you'll need to write the bootloader and do some other stuff like setup your arduino environment, because it uses the Atmega1281 processor that's not offficially supported by the tool.  If you've gotten this far and want to know how to do this, please give yourself a pat on the back and then reply to this message for further instruction. :)

Thanks,

Neil

[David P]

Thanks a lot, Neil :)

[David P]

Am Freitag, 24. Oktober 2014 22:29:48 UTC+2 schrieb Neil Jansen:

[...], because it uses the Atmega1281 processor that's not offficially supported by the tool.  [...]

BOM says ATmega1284p ... which one is correct? 

 

[Douglas Pearless]

My EMC01 board(s) are in transit and I hope to assemble one in about 1-2 weeks when all the parts have arrived.

I have and Atmel ICE/JTAG and intend to use that via a custom wiring connector to the JTAG pins on the processor to program it.

I am interested in the boot loader, etc.

Cheers

Douglas

[ICEC]

Im also listening :p

[Neil Jansen]

@David P, Atmega1281 was just a typo in my email, it should be described as atmega1284 everywhere else (bootloader, schematic, documentation, and previous emails to this mailing list)

@Douglas, the bootloader is in the repo.  It isn't JTAG though, it's an arduino that uses the standard atmeal SPI port (too much on the internet for me to repost here about how to do it).  The markdown in the repo should be enough to get you started.

--
You received this message because you are subscribed to the Google Groups "FirePick" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firepick+u...@googlegroups.com.
To post to this group, send email to fire...@googlegroups.com.
Visit this group at http://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

[Alan]

This might of been answered on reprap but I thought I would comment here so everyone can see.

I'm looking at getting 3d printing and laser going first. I see there's a marlin branch here for 3d printing. Is that intended for a mega arduino ? Can I recompile it onto a due and plug the ramp's in?

I guess I'm trying to get high accuracy.
Is it the slow delta calcs on the mega running Marlin letting it down or is it mechanical related?

I'm looking to put work in to get high accuracy. Just trying to find out where to put my efforts

[Christian Lerche]

Hi Alan.

I have tested 3D printing, and it's not accurate right now. I think, and only think, it's because you overload the Mega with calculations like sine and cosine, and that makes it slow, therefore jerky in it's movements.

I'm trying to port the delta function that Neil implemented, to my own Smoothieboard(32 bit, 120MHz ARM), to see if it helps.

If not, I will try to get a LinuxCNC going, and see if a dual-core should be able to do the calcs.
If it's still jerky (which I believe it won't be after these tests), then it must be hardware.

Regards,
Lerche

[Alan]

That's cool so your on the path already.

How intense are the calcs?

So if I made a port to a arduino due I could compare to that as well? I can't remember if the due has built in DSP math functions?

I've also got a fpga if we need some serious grunt http://papilio.cc/

[Christian Lerche]

The calcs are pretty intense, if we look at the facts:

8 bit MCU.
Calculating 32 bit floating point values.
16 MHz.

If you buff it up to Due:

32 bit MCU
Same calcs here
74 MHz (AFAIK),

You will see better/faster calculations.

I have also bought the Due, to do exactly that,
but remember, you have to either buy the RAMPS-FD, or modify the RAMPS board to accept 3V3 instead of 5V.

An FPGA will be a good choice, as it can do some fast calcs, but it's also very expensive.
As I intend to use a dedicated laptop for the PnP application and 3D printing,
I will try out the LinuxCNC, as I have found the trossen-robotics already written for it.

Regards,
Lerche

[David P]

I have an Intel Galileo lying around.
As it's arduino compatible, should'nt be too hard to make it run marlin. And the delta calculations are easier for a x86 CPU.

Other option i was thinking about is an STM32F4

-Pro:

Cheaper than the ATMega1284p

More Power

32Bit

Mbed compatible

Programmer STLink also cheap

-Con

Not arduino compatible (AFAIK)

[ICEC]

Guys Im realy bad with clock frequenties etc.
But I used to work allot with a Parallax propeller chip . thats an 8core 32bit processor . I think 20Mhz not realy sure
The propeller is a realy nice mcu , have done all sort of things with it, and its pretty capable( I think).

but not realy sure how could you compare it with what we have now.

Any ideas ?

I have an atmega1284p emc board now , but just thinking about it .
propeller can run C so should be able to cross compile, definitly will be some changes needed

Igor

[Christian Lerche]

The Parallax could actually do a nice job.

Each cog for different calcs, and all the RAM is shared so it'll be fast to take the results into other calcs.

Anybody who has seen ramps on this?

[ICEC]

Yes the different cogs approach does make a difference on how things work, but they may just work much smoother . comands running in true parallel .
think the atmega doesnt do that right ? its one command after another . sorry I have no prior atmega experiance ,always kinda avoided the arduino etc , and thats because I always used the propeller. found the spin programming easy (but slow )  been using the propeller for fun/hack things for about 6-7 years now . all sorts of sensors and small automations lcd  etc. but not a stepper sadly.
but if thats a way to go I can also look into helping with it

on there form there are allot of helpfull guys too, good place to ask for advice if its a logical thing to go at.
they have also opensourced the core files of the propeller, so now you can emulate it too in a fpga ( i havent dont it , but this is how there also woring on the propeller 2 , but thats taking verry long already but great company there)

for now I do already have the emc board ,so It wont be the first thing on my list to do

Igor

[Christian Lerche]

The mega, like all other single processor MCU's runs everthing in "series". It's possible to run an RTOS to do multiprocessing, but thats just a workaround, as it will still do it in series.

The Parallax can handle up to eight parallel processes. The problem is that the RAM can be written to and from, only at one processor at a time, because of the hub that controls it. Each cog does however have access to their own dedicated RAM AFAIK, and this can be used to store results, and transfer this to the shared memory.

[ICEC]

On Sunday, November 30, 2014 4:44:28 PM UTC+1, Christian Lerche wrote:

The mega, like all other single processor MCU's runs everthing in "series". It's possible to run an RTOS to do multiprocessing, but thats just a workaround, as it will still do it in series.

The Parallax can handle up to eight parallel processes. The problem is that the RAM can be written to and from, only at one processor at a time, because of the hub that controls it. Each cog does however have access to their own dedicated RAM AFAIK, and this can be used to store results, and transfer this to the shared memory.

I think if u let a cog store its calculated value in the shared hub , the other values used indeed will stay inside the seperate cogs .
a fourth cog will take the result of the 3 different cogs doing the delta calcs , and make the final move.

using lockbits u can garantee that no 2 cogs are reading/writing from the same adres at the same time. ( good programming takes care of that without locks)
the cogs get accese to the shared hub in a  circle acces style. one after another . but almost all commands take 1 cycle to execute , so a 32bit command wil be done on every clock tick , if I am right that is

Igor

[Douglas Pearless]

My thoughts are trying to achieve this:

https://m.youtube.com/watch?v=wdiY4GKug-I

ARM Arduino stepping 32 with0.9 degree steppers

Sent from my iPhone

> On 1/12/2014, at 12:12 am, Christian Lerche <lerch...@gmail.com> wrote:
>
> RAMPS-FD

[Paul Jones]

No offense, but I think there is a bit too much speculation here. Doing some testing to get actual answers would be a good idea.

8 bit MCUs are **TERRIBLE** at floating point. (I don’t think I can emphasise that enough J )

32 bit is sooo much more efficient.

 

Then you have the different instruction sets of AVR vs ARM. ARM has many more available instructions so more operations can be compiled down to fewer instructions.

 

If you use a Cortex M4 processor they have inbuilt DSP and Floating Point instructions, where the M3 has to emulate this with a software library. M4 processors usually have a higher clock speed as well.

 

Did you know that an M4 is easily able to decode and play MP3 files in realtime? That’s way more complicated than our application!

It’s true that SIN and COS functions are complicated, but there are ways to optimise them.

 

When I get time I’ll do some testing on various processors to see what type of performance they give. I’ll get the code that does the position calcs and run it a million times and see how long it takes.

 

Paul.

--

[Douglas Pearless]

My post did not seem to make it, so here it is again.

Have a look at this video, it is a Delta Rostock, with RAMPS-FD and Arduino Due (Cortex M3, no floating point in hardware unlike the M4), DRV8825 drivers, 0.9 degree steppers running at 1/32 stepping.

https://m.youtube.com/watch?v=wdiY4GKug-I

And this is what I shall try using to get my 3D printer part operational.

I note that the greatest benefit of 1/32 stepping seems to be a significant reduction in the noise from the stepper motors, something I would really like!

Cheers

Douglas

[Neil Jansen]

No offense, but I think there is a bit too much speculation here. Doing some testing to get actual answers would be a good idea.

This problem (delta calc speed) is pretty much solved already, but is not fully implemented yet.  It's already on the roadmap, I think people are being impatient... I won't go too much into detail about how it's going to be solved because there's already a handful of posts about it. But we already know for certain that the delta calcs take forever on the 8-bit Atmega.. Everyone knows that.  We don't need to replace the Atmega with a Due or any other ARM processor, that's just throwing money and hardware at the problem.  We already have a fast microprocessor that supports float calcs, it's the host PC that the motion controller is hooked to.  There's absolutely no reason why we can't do the calcs on the host PC, and send the g-code over in the converted format.  The only two things missing there are a switch in the Marlin code to go between Cartesian and angle input for the G0/G1 XYZ commands, and a software shim to post-process the G-code in the host software.  I will getting to both of those things very soon.  

If someone with Java and/or Marlin experience wants to lend a hand, let me know, but I've not gotten any volunteers there, other than the developers that are already helping in some way (you know who you are).  

Re: the 0.9 degree stepper motors, I do want to try these as well, I plan to buy a set next week.  But regardless of how these steppers help, the software changes above are still going to happen

 

[Douglas Pearless]

Hi Neil,

That s great to hear.  I am more than happy to help with coding just as soon as I have Maui built to a stage where it can do something useful (parts still arriving!).

One thing I note, for 3D printing, is that there does not appear to be (yet?) and interface for a J-Head hot end (or two of these) and the Mk IIB heated bed??

If this is the case, then I am happy to design one (by carving the circuit off a RAMPS-FD) and making it a stand alone circuit board?

Cheers

Douglas

[Neil Jansen]

One thing I note, for 3D printing, is that there does not appear to be (yet?) and interface for a J-Head hot end (or two of these) and the Mk IIB heated bed??

Can you elaborate a bit on that?  Surely you don't mean the EAT0001, do you?  Didn't you order a few of those a while back?

[Douglas Pearless]

Hi Neil,

<red-face>

I need another coffee!!!!

Those are exactly what I meant, but forgot they already exist and in fact, are in transit to me :-)

</red-face>

Cheers

Douglas

[ICEC]

On Monday, December 1, 2014 1:48:22 AM UTC+1, Neil Jansen wrote:

 The only two things missing there are a switch in the Marlin code to go between Cartesian and angle input for the G0/G1 XYZ commands, and a software shim to post-process the G-code in the host software.  I will getting to both of those things very soon.  

The software shim to post-proces the g-code . cant we use the prontsole.py for this , comes with printrun
 Push in command line syle . perfect for playing middle man.

The switch in the Marlin code to go between Cartesian and angle input for the G0/G1 XYZ commands, I am starting to dig into .
Finaly I have moving delta arms, so I can try out stuff.  I am waiting on the carbon rods so its stil a bit limited what i can test
but I can sure help here cause im there anyway..

Igor

 

[Neil Jansen]

The software shim to post-proces the g-code . cant we use the prontsole.py for this , comes with printrun
 Push in command line syle . perfect for playing middle man.

You could absolutely use an offline post-processor to take Cartesian G-code and convert to rotational G-code (X,Y,Z are in degrees, with 0 being horizontal).  Would probably take less than an hour to write a really simple script in Python, Ruby, Javascript, etc. to do that... BUT, there needs to be a version of Marlin that supports allowing this input... and right now we don't have that.  Will happen very soon but we're not there yet.

 

[Douglas Pearless]

Slightly off topic, for the EAT0001 board, could I use these MOSFETs in TO252 DPAK:

http://nz.apexelex.com/specs/mosfets_n_channel/AOD444.pdf

or

http://nz.apexelex.com/specs/mosfets_n_channel/U20N06.pdf

or

http://nz.apexelex.com/specs/mosfets_n_channel/U4060AL.pdf

as the FQD13N06L is rather difficult to obtain at a good price in small quantities.

Cheers

Douglas

[ICEC]

I think i better read some more before I ask silly questions, but im on it
allot of new words for me. but im getting there

[Paul Jones]

That’s a good idea actually !

 

I was originally going to use a smoothieboard that I bought for another project but it has been attached to my cnc mill now, so I bought a ramps 1.4 kit instead. I’ve nearly got enough bits to make it move now, so when I do I’ll help with the software as well. I’ve also got 0.9 deg. Steppers (they had the most torque) so I’ll see how that goes.

 

Paul.

 

From: fire...@googlegroups.com [mailto:fire...@googlegroups.com] On Behalf Of Neil Jansen
Sent: Monday, 1 December 2014 11:48 AM
To: fire...@googlegroups.com
Subject: Re: [FirePick] Re: Marlin branches for 3D printing and OpenPnP

 

No offense, but I think there is a bit too much speculation here. Doing some testing to get actual answers would be a good idea.

--

[Alan Grimmer]

I would lean the other way rather than of loading to a PC. I'm sure everyone has opinions haha. I'll just add 2cents.
The due is 5 bucks more than a uno (15 free shipping). Not sure on the actual chip cost. Fully supported by arduino ide. Can't get better than that? Oh wait there's a YouTube video of it working! No dev needed if we get that code right?

I've also got grbl running on a CNC I load gcode on, let it run. Done. Every cad and cam package I've got outputs various gcode. I wouldn't for instance be able to swap out the serial link and have it still run. Also machine settings are stored in PC not controller. I like the modular tool concept of storing settings on tool's so you don't have to change anything if you have two diff sized deltas.

I would hate to break the gcode interface as well. Its so clean its awesome, the CNC industry is gonna open up with grbl.

Also in another thread you where saying how slow the pi is and it needs a upgrade. This would further increase speed of PNP functionality right? And say you added an encoder to each axis to do closed loop control, that would need to recover from error's elegantly in xyz rather than angle in realtime by traversing the delta calcs per step.

And if there is a half way attempt I feel the format should not even try to be gcode. Make it a json format for instance, call it "acode". .angles. Then there's no chance of anyone misinterpreting it for normal gcode.

Hopefully not to ranty. Just 2 cents worth

[Douglas Pearless]

Hi Team,

Just a quick observation, I am currently bring a product to market (a USB Servo for Robotics) and am giong through the whole, design for manufacturing to get-it-made-in-China scenario at the moment (I want Firepick to help assembly some of the initial production runs of the circuit boards so I am motivated to help as I am using 0402 components and they are terrible to hand place) until I have the product all finalised and would off the following for consideration:

(1) Injection moulds that will be accurate and last a reasonable time are very expensive so use the smallest number of unique components you can, keep them very 'clean and simple'.

(2) I wonder if the current ATMega and tool boards is really gong to be cost effective, given you can buy a RAMPS-FD board for USD$18 and a Arduino Due for $26 (there is a clone of this that has more I/O too) which has a lot of processing horsepower, though I do note that the intention is to push the heavy lifting to the host to deliver the pre-calculated paths and instructions for the ATMega to just execute, which if successful, would be a good move.

(3) While I love the Raspberry Pi, I suspect that it will run out of processing power with OpenCV, especially if we end up with quite a large database of parts.

(4) To really reduce cost, it might be worth moving all but the real-time control of the motors (etc) to the host, continuing on the path of the host doing all of the work in a operating system independent manner, deleting the raspberry Pi, LCD, etc so you only have the ATMega and a cheap USB to TTL cable (only a few $) and a low cost USB camera (perhaps a low host USB Hub if required), so the sum of the electronics is the ATMega, tool boards, opto boards, camera and a power supply.

Just my 2 cents worth that will hopefully spark some positive debate.

Cheers

Douglas

[Neil Jansen]

I would lean the other way rather than of loading to a PC. I'm sure everyone has opinions haha. I'll just add 2cents.
The due is 5 bucks more than a uno (15 free shipping). Not sure on the actual chip cost. Fully supported by arduino ide.

Not sure where you're getting those prices.  From all the vendors I've seen, there's about a $19 price difference.  The chip itself is $7.50 more than the atmega1284p, and that doesn't include all the extra glue logic, power supplies, another crystal (it requires 2), second micro USB port, etc.. FirePick is meant to be an integrated solution, to get the prices down, rather than stacking boards like the RAMPS is commonly done now.

Can't get better than that? Oh wait there's a YouTube video of it working! No dev needed if we get that code right?

That's not entirely correct.  I'm pretty positive that you'll find that whatever motion controller firmware you're referring to does not have the rotational delta calcs implement, nor the proper homing sequence for a rotational delta.  No matter how you look at it, you're going to need a dev, be it myself or someone else, to add all that stuff in.  It's not impossible, it might only be trivial, but it's not an out-of-the-box solution, as-is.  

I've also got grbl running on a CNC I load gcode on, let it run. Done. Every cad and cam package I've got outputs various gcode. 

 100% agreed.  But what I proposed doesn't stop you from being able to load standard gcode output into FPD.  The only difference is, you're doing it through OUR interface (whether web enabled or otherwise), rather than some vanilla gcode program like the ones commonly used for GRBL or Pronterface or Mach3 or whatever.  You give our frontent UI software industry-standard Gcode (with or without Marlin-supported M-codes).  We'll handle it from there.  The rest is completely transparent to the user.

I like the modular tool concept of storing settings on tool's so you don't have to change anything if you have two diff sized deltas.

Most people here don't, so at least we've got that in common ;)

 

I would hate to break the gcode interface as well.

Who said I was breaking the gcode interface?  I'm just sending it in a different mathematical format, to offload the calcs.  Every other bit of the gcode is identical to what it was.  It's a compromise that some project wouldn't take but it's a compromise that I want to take.  It saves us from using an ARM chip and again, it's transparent to the user.

You know how there's a lot of drama in the Linux / FOSS communities, where forks happen because of little details that the user would never see?  Well that's exactly what's going on here (hopefully it's just drama and no plans of forking, heh).  Systemd and Gnome come to mind... there are others.  At the end of the day, FPD has a philosophy, it's what's gotten us this far (that philosophy btw, is mechanical simplicity at the cost of software complexity, to save cost).  Everyone that got here from the Hackaday.io page already knows that, whether or not they agree with it.  If people want to do a really simple vanilla Cartesian machine, then Jason's OpenBuilds might be better (heck I'll probably make one soon).  If someone wants an expensive deltabot, then they can go right ahead.  But neither of those things fit the philosophy of FPD.  The only thing my future customers care about is price, otherwise they'd just buy a used commercial PnP machine, or a crappy new one from China.

 

Also in another thread you where saying how slow the pi is and it needs a upgrade. This would further increase speed of PNP functionality right?

The Pi is slow, but adding a few delta calcs isn't going to kill it.  It's already doing OpenCV calcs without much complaint, so no I don't think it will have the slightest effect on speed.

 

And say you added an encoder to each axis to do closed loop control, that would need to recover from error's elegantly in xyz rather than angle in realtime by traversing the delta calcs per step.

That will never, ever happen on FirePick Delta.  If people want really sophisticated machines, they can go out and buy a $20,000 USD used machine with glass scales and ballscrews and whatnot.  That's not what this machine is about.  If you're losing steps anyway, you're doing something wrong.  And besides, we can use the camera for homing, which is already mostly implemented. 

 

And if there is a half way attempt I feel the format should not even try to be gcode. Make it a json format for instance, call it "acode". .angles. Then there's no chance of anyone misinterpreting it for normal gcode.

I don't see any point in making yet more formats.  Like I said, everything is transparent to the user, we (or I) just have to write the software.  It's coming, very very soon.

Hopefully not to ranty. Just 2 cents worth

Not any more ranty than I am on a good day... lol.  

[ICEC]

Just a quick reply on that and on Alans reply

Any way you put it , the Rpi is hopelessly underpowered to do the job for what the FPD has come to have to do .
OpenCV will eat allot. ever tryied live streaming from a rpi ( verry buggy) , doing calscs cause the atmega also cant, running a server maybe for easy acces/interface . communications back and forts between (emc <-->host-Rpi <--> interface on diferent pc )
the rpi will have a very veryy veryy veryy hard day of work .

The idea is to use a full powerd host for the momet to develep the software (wich may take time, but give smoother results)
 and when it all works you can better size what kind of systems suits best. a Mini ITX powered by Intel Atom mentiond by Neil in the bbb post as example .
or any other one of the dozens of small board pc , pop in a sd card and for $100 you get quite some power .
does add some cost, but will do all the heavy lifting. no mpre trouble trying to tweak everything to fit and work in RPI

bye the way, your always free to keep using the RAMPS board and not the EMC ,if thats turns out cheaper cause of all of the clones ,
its a easy change in marlin, so its a choice thing. both will work the same as they have the same mcu

id say your number 4 point is correct

Igor

[Neil Jansen]

Just a quick observation, I am currently bring a product to market (a USB Servo for Robotics) and am giong through the whole, design for manufacturing to get-it-made-in-China scenario at the moment (I want Firepick to help assembly some of the initial production runs of the circuit boards so I am motivated to help as I am using 0402 components and they are terrible to hand place) until I have the product all finalised and would off the following for consideration:

This is the kind of stuff FirePick Delta was made to do, so I wish you the best of luck.  

 

(1) Injection moulds that will be accurate and last a reasonable time are very expensive so use the smallest number of unique components you can, keep them very 'clean and simple'.

100% agreed.  This is why I think the ESD-safe 3d printed feeders are so awesome.  No need to make 20 different injection molded feeder parts, that will probably change down the line.

 

(2) I wonder if the current ATMega and tool boards is really gong to be cost effective, given you can buy a RAMPS-FD board for USD$18 and a Arduino Due for $26 (there is a clone of this that has more I/O too) which has a lot of processing horsepower, though I do note that the intention is to push the heavy lifting to the host to deliver the pre-calculated paths and instructions for the ATMega to just execute, which if successful, would be a good move.

I can make the EMC01 for 1/2 of that easily.  So yes it will be cost effective.  Also I don't have to rely on cheap Chinese clones (remember FTDIgate? ).  I've had trouble with Chinese clones in the past.... There's NO guarantee that they're putting the right MOSFETS on the board with low RDSon... Geeetech screwed that up a while back (link is here: http://reprap.org/wiki/Melzi#Melzi_Issues_.28Geeetech.29 Notice it was me that discovered the problem in the first place, that the boards would go up in smoke at an in-opportune time... They didn't really do anything about it for weeks or months.. And they're considered more reputable than a no-name shop).  Again, I'm not trying to bash on Chinese vendors here.  I'm just trying to point out that if you want to ensure quality, you've got to do it yourself.  And the whole idea behind setting up Micro-Factories like we'er doing now, is to compete directly with the Chinese... and that's what I'm going to do.

 

(3) While I love the Raspberry Pi, I suspect that it will run out of processing power with OpenCV, especially if we end up with quite a large database of parts.

Premature optimization is the root of all evil.  Therefore: 

• Get it working first.  
  
• Then run metrics.  
  
• Then (and only then) decide if you need to go back and optimize it or upgrade CPU power.  
  

 

(4) To really reduce cost, it might be worth moving all but the real-time control of the motors (etc) to the host, continuing on the path of the host doing all of the work in a operating system independent manner, deleting the raspberry Pi, LCD, etc so you only have the ATMega and a cheap USB to TTL cable (only a few $) and a low cost USB camera (perhaps a low host USB Hub if required), so the sum of the electronics is the ATMega, tool boards, opto boards, camera and a power supply.

That's exactly what I'm doing right now (I can fish up earlier posts by me saying exactly that, there are dozens and dozens of posts on this, too many to repeat here).  I'm basically getting it working on my Windows PC using Eclipse Java, and will be doing that for quite some time before I try to shrink everything down to the Pi.  If people don't want to buy a Pi and want to use a regular Mac / Windows / Linux PC, they can do that.  But I really want to get an embedded version done shortly thereafter, once the code has stabilized.. using Raspberry Pi or whatever else is available at that time.

[Neil Jansen]

Any way you put it , the Rpi is hopelessly underpowered to do the job for what the FPD has come to have to do .
OpenCV will eat allot. ever tryied live streaming from a rpi ( verry buggy) , doing calscs cause the atmega also cant, running a server maybe for easy acces/interface . communications back and forts between (emc <-->host-Rpi <--> interface on diferent pc )
the rpi will have a very veryy veryy veryy hard day of work .

I'm wondering how many people on this forum, besides Karl and myself, have actually used OpenCV on the Raspberry Pi?  It works just fine and CPU times are not that long at all.  It's not as under-powered as some people here think.  I know this first-hand because I've used it.  Karl has even been nice enough to graciously post compute times of various pipeline stages on various architectures, to demonstrate this.  It's on the firesight wiki if anyone wants to check it out.

 

bye the way, your always free to keep using the RAMPS board and not the EMC ,if thats turns out cheaper cause of all of the clones ,
its a easy change in marlin, so its a choice thing. both will work the same as they have the same mcu

 Yes.  Personally I'm supporting the EMC01 because 

• the machine wiring is cleaner, 
• it supports more tools than the RAMPS, 
• I can guarantee that the parts are genuine and not cheap chinese garbage,
• and it will likely be cheaper, depending on the quantities that I buy the parts and boards in (although everyone is correct that at this time, RAMPS+ArduClone+CloneStick is cheaper because they're made in such high quantities).
  

But anyway, yea, you can use RAMPS 1.4 or a RAMPS FD or whatever.  Github is a magical thing that supports forks and pull requests.

[Karl]

The RPi is a starting point.
We will move beyond.
But I do like the PiCam.
And there is no need to do all OpenCV
on the RPi--but it clearly can do some.
Thanks to Neil, we now have a FireSight that
can run on desktop platforms supported by
continuous integration releases.

[Peter Shabino]

FYI realtime motion control on a host PC / Rpi / ect without dedicated hardware is a major pain and does not work out well. Most modern PC running motion control without dedicated hardware max out around 40kHz or less due to timing jitter from interrupts / power management (some are processor level and cannot be disabled).

Solution is to have a hardware offload that takes care of the stepper motor timings and keeps track of where things are. The PC host just feeds it instructions to a que that is processed when the previous one finishes. This eliminates the host PC and OS timing jitter. One of the more famous ones is smooth stepper which is based on a FPGA. 

So the ATMega doing the timing generation is actually a good thing. Just need to offload the math to the host pc and I think things will work well. 

If anyone wants to look at another route I am doing some updates to the PICnc firmware and HAL driver for linuxCNC. This is a Rpi (or any other single board with a high speed SPI interface) breakout that can do 19 outputs / 5 axis (step/dir pairs) / 4 hardware PWM channels / 12 inputs. If I could redo my hardware again I would move to the next larger package for a few more IOs and a higher max internal clock rate. That said what I have now works so far just need to finish up some xmas presents so I can get back to firmware updates and debug.

BBB seems to be a unique beast in this case. Apparently it has some built in micro cores that can be accessed from the main processor. So they can be dedicated to step gen / IO processing while letting the main processor run the linuxCNC software and OS. I have not played with a BBB so not sure how accurate this is. Just saw a blurb about it a while back on the machinekit site. 

Later,

Peter

My projects:
http://www.wire2wire.org/

---

Date: Mon, 1 Dec 2014 12:31:33 -0800
From: douglas....@gmail.com
To: fire...@googlegroups.com
Subject: [FirePick] Re: Marlin branches for 3D printing and OpenPnP

[Alan]

Whoops this really is a hot topic, i just searched the forum and found the other posts.

I think having a select able option in marlin is the way to go. recompile for standalone with on board calcs or compile for off board with angle gcode input (still reckon it should be called acodes!). This solves my dev needs of using it as a laser engraver from grbl gui's while the main app catches up

I got my due on aliepress for $15 free shipping including the usb cable!, http://www.aliexpress.com/snapshot/6087000130.html its not listed anymore but i can confirm i received one from that exact page.

I think lots of us are getting close to twitching machines hence why this topic came up again. I'm a few parts away myself.

[Neil Jansen]

I think having a select able option in marlin is the way to go. recompile for standalone with on board calcs or compile for off board with angle gcode input (still reckon it should be called acodes!).

Why does it have to be compile time configurable?  Why not just make it a software switch like I mentioned above?  It defaults to code ON (which works now, as Christian, myself, and others have proved), albeit a bit wavy prints but still usable!  Can be switched OFF by M-codes, so you can use a custom frontend (the one we're writing that's web-enabled) that does the calcs and sends those over? 

 

I got my due on aliepress for $15 free shipping including the usb cable!, http://www.aliexpress.com/snapshot/6087000130.html its not listed anymore but i can confirm i received one from that exact page.

Whoever can get Arduino Due working in the same fork that I'm working out of, I'll send you free stuff if you send me a pull request.  How's that?

I think lots of us are getting close to twitching machines hence why this topic came up again. I'm a few parts away myself.

Pics? :) 

[Roy Nielsen]

When I've completed a bit more of my degree plan, I'd like to try getting it working on a pcduino nano:

http://www.linksprite.com/?page_id=815

Regards,
-Roy

--

[stonecold Liang]

I try to download the 3d print Marlin to Ramps1.4 of my FirePick with E3D hotend toolhead(design by myself) for the first run, it move, but many problems,I will collect errors and hole  the team can help me .

在 2014年10月25日星期六UTC+8上午4时29分48秒，Neil Jansen写道：

All,

I've added some branches to the FirePick Delta Marlin fork, which is the motion controller software that runs on the EMC01 (or RAMPS 1.4 for the alpha folks that don't have one yet).  I've also done some housekeeping and cleaned up the other branches.

3D printing Functionality in branch: "Feature/3dprinting"
Works with RAMPS 1.4, J-Head, Wade's extruder, opto endstops, and heated bed.  You will still need to go through the config and configure your extruder and thermistor hotend, steps per mm, and all the other stuff that must be done if you're not buying a kit where someone did all that work for you.  This is one of the things that I really don't like about the current Marlin firmware, and it's one of the things that will be solved with our Modular Tool System in the EMC01 motion controller.  For example, the thermistor values and steps per mm will be stored in the tool, so you don't have to mess around with firmware at all once it's done.  In the meantime though, it will require a bit of patience and trial and error to get the config.h (and pins.h)  fully setup on your machine.  This is something that will come easier to the folks like Christian and myself that have built RepRap's from kits or from scratch. We can certainly try to help here if anyone has any questions, we're here to help.

Link: https://github.com/firepick-delta/marlin/tree/feature/3dprinting

Pick and place Functionality in branch: "Feature/Openpnp"
Works with RAMPS 1.4 and a hollow-shaft NEMA 8 motor.  No powered SMT feeders supported at the moment, or 3D printing functionality.  Right now, this is a separate branch, because OpenPnP needs the Z=0 to be somewhere in the middle of the work area.  That's because it uses zero as the "safe Z" level, and that can't be at the top or the bottom of the work area with this delta config.  I know how to get this fixed, but right now, it's all about baby steps and priorities.

Link: https://github.com/firepick-delta/Marlin/tree/feature/openpnp

Bleeding-edge development in branch: "Dev"
This branch will be devoted to getting the EMC01 fully supported with the modular tool system, and making the system 3D print and do Pick and Place, all without having to switch back and forth.  Consider this unstable until further notice.  If you have experience with the Marlin firmware and would like to help, please let me know, I'd be very grateful.

Link: https://github.com/firepick-delta/Marlin/tree/dev

Also note, if you happened to get your hands on an EMC01, you'll need to write the bootloader and do some other stuff like setup your arduino environment, because it uses the Atmega1281 processor that's not offficially supported by the tool.  If you've gotten this far and want to know how to do this, please give yourself a pat on the back and then reply to this message for further instruction. :)

Thanks,

Neil

[Alan]

My ramps-fd V1 arrived and I've got it twitching steppers now, next is delta code.

Marlin version for due is here https://github.com/bobc/Marlin/tree/Marlin_v1

I'm just about to do some diff's and see how I can add the delta's calcs in.

Is this the latest still for FPD marlin? https://github.com/firepick-delta/marlin/tree/feature/3dprinting 

Should I branch from here and make changes?

Cheers,

Alan

[Ray Kholodovsky]

Alan - Regarding sourcing, A+A+A+ is where I got pretty much everything.  They either merged or were involved in a hostile takeover (hostile takeover is a more fun story).  In either case, the new company is called FAR EAST ELECTRONICS.  I just got some gt2 pulleys and teflon from them, delivered a few days ago, and ordered more stuff.  Just search the name on google and the aliexpress link should be amongst the first few results.  

[Douglas Pearless]

While I am waiting for the last of the hardware to arrive, and time to assemble the PCB's that I have, I have turned my attention to the software.

 

I now have a functioning Raspberry Pi B+ and camera, and I have installed FireREST (etc) and I am now reading the documentation on the WIKI, plus I have been over to Octoprint and had a look at their site.

 

Before I get too deep into things, a couple of questions.

 

(1) Why are things enumerated from 1, when it is more common to enumerate from 0? ( e.g.  http://firepick:8080/firerest/cv/1/gray/camera.jpg rather than http://firepick:8080/firerest/cv/0/gray/camera.jpg ) this seems a bit odd, is there a reason for this?

(2) Where is the proper place to discuss the software development, who is doing what, the state of things (pardon the weak pun), etc

 

Cheers

Douglas

[Karl]

Douglas,

Non programmers are always thrown off by zero indexing. I chose 1- indexing expecting that non programmers would be configuring FPD. Looks like I ended up confusing the programmers. Very sorry. I suppose you shall have to come up and toss me in the pool. :)


I have been neglecting the software because I needed a well defined tool / camera interaction model. For example I really didn't want to have a complex homing model--it was actually easier to make homing simpler by slicing the pulley.

[Douglas Pearless]

OK, lets go back to 0 based enumeration, like all proper programs :-)

While I see there is a high level architecture, has anyone captured the business requirements (high level and detailed) and written a software specification?

One of the obvious questions is has anyone written code to take a PCB (e.g. the gerber files ) and construct an image, then use the camera to find it, and figure out it's orientation?

etc.

Cheers
Douglas

[Douglas Pearless]

I was thinking that this is interesting, perhaps the start of some code to generate an image of a pcbs to compare with the camera? https://github.com/dustinbcox/pcb_drill

or maybe this http://gerbv.geda-project.org

thoughts?

[Karl]

Douglas,

We've found that PCB recognition is simplest via fiducial rather than by whole image match of the PCB. Simon's Hough circle recognizer could be used for PCB's without fiducials, but I think that would be a secondary use case. The specific layout of any PCB is of little use in recognition because the hole positions wouldn't vary from board to board and are determined by the drill files. There might be some use to the operator in presenting an image of the PCB model as an overlay for feedback or circle recognition. This might be incorporated as a FireSight stage that reads a drill file and generates the corresponding image within a given origin, orientation and scale. As such it could be used for operator feedback, especially if we amended the drill file with information about parts as they are placed by OpenPnP. 

Regarding the business plan, in Jason's OpenPnP discussion group you will find a lot of discussion about PnP business cases. There seem to be two primary use cases: 1) home hobbyist wanting to make 3-10 PCBs (decrease cost, save time, eliminate drudgery, have fun, etc.) and 2) small biz pnp with 20-100 PCBs in a customer job. The requirements are actually split along those lines quite markedly. Tray/strip feeders suit #1 just fine. Auto feeders suit #2 better. Drag feeders are somewhere in between. Neil and Jason are more interested in #2. I am more interested in #1 with a focus on vision recognition. You've also seen this split in the FirePick newsgroup with some folks pushing for desktop CPUs and serious throughput vs. hobbyist Pi folks. FPD spans both use cases and it's always important to clarify our design intent with respect to each use case. 

[Neil Jansen]

While I see there is a high level architecture, has anyone captured the business requirements (high level and detailed) and written a software specification?

Are you getting a burning itch to do some backseat management on our project there, Douglas?   To answer your question, yes, I have all of that stuff written and ready to go.  At this point I don't need people second guessing our requirements process. What is needed, in my opinion, is people to step up and actually contribute meaningful code to the repo.  

We've got 177 members on this developers mailing list at my last count, and maybe 4-5 people that have contributed meaningful code and cad files, and less than a dozen that have contributed to the repo in some small way.  I think we've gotten 2-3 pull requests, total.

Less backseat driving.

More code contributions... please :-/  

The OpenPnP group was the same way (sorry Jason).  A bunch of people standing around waiting for others to finish the work.  That's not what an open source developers community is supposed to be about.  It's very disheartening.

If there's something that I can do to make this happen, please let me know.  

That's not supposed to come off as a rant.  I'm honestly opening this up to all 177 members, what can I do help people here contribute this project?  This is a developers mailing list, what's stopping you?  I know the high level details are scattered, but they're there.  I personally really know what I want for this project software wise, and can give direction there.  Karl can as well.  'm readying kits at this point in time, and that's a huge effort that has already taken sacrifices from my family and my sanity, and over $15,000 USD that I may never see again.  I'm hoping we'll get more code contributions once we get kits out there.  HOWEVER there's work to do TODAY, if you're really interested in helping.  Some of you have some holiday time out, and I know we have a lot of really smart people here.  If there are any barriers standing in anyone's way, 

If I can get some real honest answers, even if it's constructive criticism on the way I've managed FPD so far, I'll do everything I can to get this project moving. 

-N

[da...@dalewheat.com]

My two cents on project management, as it may or may not apply to this project:

What is presently lacking is 1) assignment/ownership, 2) expectations and 3) accountability.  Other than that, we're off to a great start!

When handling an emergent situation, for example, you DON'T yell "Someone call 9-1-1!" and hope for the best.  You point to the person closest to a phone and say, "You!  Call 9-1-1".

We need a mechanism for assigning both large-scale and small-scale tasks to specific individuals or organizations.  These assignees would then have the authority to accomplish the task(s) assigned to them.  How do you know if some stranger on a web forum has the chops to pull off the job?  You don't at first.  Try and fail.  Repeat.  Learn.

This brings us to expectations.  They have to be spelled out in detail.  Think of a punch list on a construction job.  When the list is finished, the project, or sub-project, is done.  You have to have that list ahead of time, unfortunately.  Open-ended assignments are kryptonite to enthusiasm.

And there must be accountability.  To shrug and say, "Well, it's a volunteer effort" is to let everyone off the hook from ever getting anything done.  Get your stuff done on time and under budget, or be replaced.

Some of us already have jobs and can only devote a small amount of time & energy to the cause.  Some of us already have hobbies that may or may not be jealous of yet another project.  Do bear that in mind before volunteering for duty.

Some of us are here for the journey, while others are waiting impatiently for the destination.

Today the FPD is a cult.  We have a charismatic leader with a clear vision of what he wants to accomplish, and how it will benefit future users.  And Neil helps out a lot, too  :D  Tomorrow the FPD will be both a successful business enterprise and a fantastic example of open source at work.  So many people *will* benefit from this project.  But until we get a total brain-dump of The Plan, on paper, it remains a rumor.  I don't see that it's out of line for Douglas to ask if these necessary documents exist yet.

Thus endeth the rant.  Let's continue to "be excellent to each other" here.  Reply to me directly at da...@dalewheat.com if you like.  Now I can get on with my post about RPiB+ and cameras at Microcenter.

[Roy Nielsen]

Hello,

My apologies, with school and other commitments, I haven't had the time to put into the project that I've wanted to yet. 

In software projects I've worked on, even though they've been managed slightly differently, they've all had a posted list of stuff to do.  People can then choose what to contribute to, comment on, suggest directions to take an issue via some kind of web project management software (sourceforge, trac, redmine) to track the progress of the requirements/bugs/feature requests. 

Github has "issues" that can be used to track issues with a project, we could use that if we wanted - but I think Dale and Douglass have it right - the requirements need to be posted somewhere.  It would be easier for contributors to pick a direction to start with.

If some kind of ticket/issue tracking system were used - it's like a checklist - making sure it's posted what requirements get met when, what's left to do, some idea of the scope of what's  left to do to meet the next deadline (1.1.0 -> 1.1.1)

When I last participated in an open source project, they had a fairly mature project tracking system - hundreds of ticktes (bugs, feature requests, requirements to meet, etc).  I had a need, and some agreed it would be a good feature, but no one was willing to implement it.  After cutting through tons of red tape at work(another story entirely), I finally got permission to participate in the project, and added a few characters to a file and submitted my change(www.puppetlabs.com puppet project).  But the important thing was that the issue was tracked, comments were tracked from inception to completion.

Puppetlabs uses Redmine (my favorite).  Using some kind project management system like sourceforge, track or redmine might help get some people focused enough to contribute to something specific.  I'd be happy to help there as I've managed these types of systems before, but I've been under some time constraints to get some things done for my job, school and other commitments.  If you are interested and would like someone to take a look at getting one set up, I'll make some time during winter break to do that.  Both school and work are closed down for about a week and a half, and I'll spawn a bunch of threads to get all my winter break projects worked on :)

Let me know what you think,

Regards,
-Roy

[Neil Jansen]

In software projects I've worked on, even though they've been managed slightly differently, they've all had a posted list of stuff to do.  People can then choose what to contribute to, comment on, suggest directions to take an issue via some kind of web project management software (sourceforge, trac, redmine) to track the progress of the requirements/bugs/feature requests. 

Github has "issues" that can be used to track issues with a project, we could use that if we wanted - but I think Dale and Douglass have it right - the requirements need to be posted somewhere.  It would be easier for contributors to pick a direction to start with.

If some kind of ticket/issue tracking system were used - it's like a checklist - making sure it's posted what requirements get met when, what's left to do, some idea of the scope of what's  left to do to meet the next deadline (1.1.0 -> 1.1.1)

When I last participated in an open source project, they had a fairly mature project tracking system - hundreds of ticktes (bugs, feature requests, requirements to meet, etc).  I had a need, and some agreed it would be a good feature, but no one was willing to implement it.  After cutting through tons of red tape at work(another story entirely), I finally got permission to participate in the project, and added a few characters to a file and submitted my change(www.puppetlabs.com puppet project).  But the important thing was that the issue was tracked, comments were tracked from inception to completion.

Puppetlabs uses Redmine (my favorite).  Using some kind project management system like sourceforge, track or redmine might help get some people focused enough to contribute to something specific.  I'd be happy to help there as I've managed these types of systems before, but I've been under some time constraints to get some things done for my job, school and other commitments.  If you are interested and would like someone to take a look at getting one set up, I'll make some time during winter break to do that.  Both school and work are closed down for about a week and a half, and I'll spawn a bunch of threads to get all my winter break projects worked on :)

Requirements are really tough, because they move around day to day.  We're not doing waterfall-type requirements and software development (both Karl and I got too much of that at our day jobs).  The agile approach works better for us, and I've found Trello to be a great way to keep track of tasks and user stories.  Github Issues are currently enabled for all of the repos (if they're not I can turn them on).  I like Github issues a lot, however there's not much activity going on there... If people are finding issues or have input, it's not being used like it could.

It's also got a bit more complicated because Karl and I are working on two somewhat-different software architectures, and somewhat-different mechanical architectures (although there's more similarity between them than differences).

We have an outdated Trello board that we were using, probably 6 months ago. It was limited to a core group of FPD developers (the HaD competition team back when that was a thing), because I learned from a wise person once, that collaboration works better in a smaller group.  Most of the HaD team have gotten busy with other stuff or have moved on, so it's basically sort of gathering dust now.

If there are some people eager to start helping, I can revive the Trello board and invite people to it.  

[Roy Nielsen]

Hello Neil,

>
> Requirements are really tough, because they move around day to day.
> We're not doing waterfall-type requirements

Ok, tasks, user stories, goals, some kind of target for people to shoot
for, that has some level (very general to somewhat specific) of
specification.

> and software development (both Karl and I got too much of that at our
> day jobs). The agile approach works better for us, and I've found
> Trello to be a great way to keep track of tasks and user stories.
> Github Issues are currently enabled for all of the repos (if they're
> not I can turn them on). I like Github issues a lot, however there's
> not much activity going on there... If people are finding issues or
> have input, it's not being used like it could.

At work, we use Team/Source Forge to keep track of tasks and user
stories for our current big scrum project. I haven't worked on a
waterfall project for 12 years :)

> It's also got a bit more complicated because Karl and I are working on
> two somewhat-different software architectures, and somewhat-different
> mechanical architectures (although there's more similarity between
> them than differences).
>
> We have an outdated Trello board that we were using, probably 6 months
> ago. It was limited to a core group of FPD developers (the HaD
> competition team back when that was a thing), because I learned from a
> wise person once, that collaboration works better in a smaller group.
> Most of the HaD team have gotten busy with other stuff or have moved
> on, so it's basically sort of gathering dust now.
>
> If there are some people eager to start helping, I can revive the
> Trello board and invite people to it.

Sounds like a good idea - Is there a way on Trello to compartmentalize
or organize the two projects?

Regards,
-Roy

[Neil Jansen]

On Wed, Dec 24, 2014 at 11:57 AM, Roy Nielsen <amr...@gmail.com> wrote:

Sounds like a good idea - Is there a way on Trello to compartmentalize or organize the two projects

Basically the current breakdown is more or less:

• Mechanical (FirePick Delta trunk / Neil)
• Mechanical (FPD-LooseCanon / Karl)
  
• OpenPnP (openpnp.org trunk / Jason von Nieda)
• OpenPnP (FirePick Delta fork / Neil)
• FireSight (firepick1 trunk / Karl)
• FireSight (FirePick Delta fork / Neil)
• FireFUSE / FireREST / RasPi integration (firepick1 trunk / Karl)
• OpenPnP / usbcam / Win/Linux/Mac integration - Neil
• Marlin FPD fork - Neil
• Web app integration and REST API for OpenPnP - not yet assigned, has been discussed with a few folks

Each of those ideally would get a trello board, although some need it more than others.  Realistically, the mechanical stuff has turned out to be really hard to collaborate on, which is why Karl and I have separate forks.  I think the GH-Issues are a important way to handle the various day to day stuff than trello, as Karl and I both more or less know what some of the mechanical stuff should be in our head, and the other half of that is sort of flying by the seat of our pants and seeing what works and what doesn't, through a lot of iteration and printed prototype pieces.  That's also being finalized at the moment so should be less of an issue once it's officially released.  OpenPnP is also a bit tricky because Jason is only loosely affiliated with FPD, he's building his own stuff and doesn't want to get stretched too thin.  He has a trello and probably has a good game plan for what he needs for a generic OpenPnP.  For FPD however we need some very specific functionality added to OpenPNP.  I have a card stack on Jason's trello now for that, I might be able to move/copy that to a new board and open that up to other Java developers interested in helping (which is pretty much just been myself and Armin so far, with a lot of help from Jason).  Marlin changes are actually pretty simple and I think I can get the changes I need done quicker than what it would take me to write it all up and have someone else do it.  The web app is something that I've got a lot of ideas for, but that's a feat upon itself that will need a lot of very careful development, from very experienced web app developers, with an eye for user interface design, intuition, and ease of use.

So yea, it's a mess, a lot of the info's out there already, some of it's current, some of it's outdated, some if it's scattered, and some requires reading in between the lines as it's not exactly spelled out.  I'm open to suggestions.

[Roy Nielsen]

Hello Neil,

Sounds like tracking hardware wouldn't be useful right now, maybe some configuration management of the designs might be a good idea once there are stable versions.

Recommendations/suggestions below:

Basically the current breakdown is more or less:

• OpenPnP (openpnp.org trunk / Jason von Nieda)
• OpenPnP (FirePick Delta fork / Neil)

Maybe people could choose to participate in one or the other of the above (making a trello board for the FirePickDelta fork)

• FireSight (firepick1 trunk / Karl)
• FireSight (FirePick Delta fork / Neil)

How about having one trello board for these, but give some kind of indication on each card which branch its for?  (haven't used trello before, so I don't know if that would be useful)

• FireFUSE / FireREST / RasPi integration (firepick1 trunk / Karl)

One trello board for this.

• OpenPnP / usbcam / Win/Linux/Mac integration - Neil

If this really is separate from the two above, a trello board for this

• Marlin FPD fork - Neil

Leave this for later once there is a known working baseline.

• Web app integration and REST API for OpenPnP - not yet assigned, has been discussed with a few folks

I'd have a board for this, but maybe only for people that have proven experience?  That might give the web app a good head start.

So yea, it's a mess, a lot of the info's out there already, some of it's current, some of it's outdated, some if it's scattered, and some requires reading in between the lines as it's not exactly spelled out.  I'm open to suggestions.

You and Karl are really busy with mechanical and beta logistics right now, maybe if someone "in the know" can take a a bit of time and put together the trello boards during the holiday break?

Regards,
-Roy

[Alan Grimmer]

My 2 cent's worth ...

On the mech side I find it very hard to find out what's latest. Karl or Neils fork for instance just made my head spin. I decided awhile back when I started to freeze a build and don't upgrade anything until its hit beta.  then I would build a second machine from scratch.

At this point in time there's the two forks emerging and I like both sides. Time will tell which win's. Personally if they merged back to one double awesome machine it would make it easier for me.

On elec side I've got the impression it's not going to change and adding horse power was a hot debate. Its ok its just the opposite stage to the mech. If there we're a high level on this I think we could all vent ideas there. I would of expected the hardware to change more since we will all have PNP gear to make new idea's quicker and it's the core skill of the group

On the software side I've just started diving into marlin with my due experiments. Even then the rest of the software parts feel like there's a million different things going on and it's quite hard to see what state each is in. E.g. I'm porting marlin to a due but how can I tell if the current marlin branch has any issue's/ features I should look out for or add?

So I guess after pointing this stuff out, a high level of the direction and task list's would be helpful. And knowing where the Karl and Neil differences will goto. E.g. join back... Separate hardware and software?
And uses case's. E.g. I use it as 3d printer / laser engraver will I use the same GUI as pnp?

--
You received this message because you are subscribed to a topic in the Google Groups "FirePick" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firepick/rrvXWsAfVKU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firepick+u...@googlegroups.com.

[Douglas Pearless]

Well I seem to have triggered an interesting debate.

For my sins, I manage complex IT programmes and projects, including software developments.

While I am very busy, if wanted, and not to step on anyone's toes, I am happy to look at picking up and formalizing the overall management of the development process to free others up to do the actual development ( I also still program as a hobby ).

And lastly, wishing everyone a happy holiday / Merry Christmas.

Cheers

Douglas

Sent from my iPhone

[Neil Jansen]

On Wed, Dec 24, 2014 at 3:02 PM, Alan Grimmer <alang...@gmail.com> wrote:

On the mech side I find it very hard to find out what's latest. Karl or Neils fork for instance just made my head spin. I decided awhile back when I started to freeze a build and don't upgrade anything until its hit beta.  then I would build a second machine from scratch.

At this point in time there's the two forks emerging and I like both sides. Time will tell which win's. Personally if they merged back to one double awesome machine it would make it easier for me.

They may merge back together at a later date, but as of right now they serve separate yet important purposes.  A lot of people want a production-ready kit that can be purchased, and others can't wait and want to build one now. Also, Karl really doesn't want to get involved with all the businessy stuff I'm doing like sourcing and whatnot. 

 

On elec side I've got the impression it's not going to change and adding horse power was a hot debate. Its ok its just the opposite stage to the mech. If there we're a high level on this I think we could all vent ideas there. I would of expected the hardware to change more since we will all have PNP gear to make new idea's quicker and it's the core skill of the group

There will definitely be a higher-horsepower version down the line, but I was (and still am) very adamant that's not exactly needed now, especially since the majority of people that have reached out to me want this thing to be extremely cheap, which means that even $40 increased cost is too much.  Getting something like this under $1000 is extremely hard and when you 

 

On the software side I've just started diving into marlin with my due experiments. Even then the rest of the software parts feel like there's a million different things going on and it's quite hard to see what state each is in. E.g. I'm porting marlin to a due but how can I tell if the current marlin branch has any issue's/ features I should look out for or add?

Yes, it's a mess, there's not a whole lot you can do about it other than to do your best and see what doesn't work.  Luckily the core of Marlin doesn't its job very well so if you stay out of the planner / processor for the most part, and understand how stuff gets handed over there, the rest is just fluff.  Really ugly, badly written fluff. lol.

 

So I guess after pointing this stuff out, a high level of the direction and task list's would be helpful. And knowing where the Karl and Neil differences will goto. E.g. join back... Separate hardware and software?
And uses case's. E.g. I use it as 3d printer / laser engraver will I use the same GUI as pnp?

Any suggestions with where to store that or how would be appreciated.  My preference would be somewhere central.  The github wiki pages are sort of a mess, you end up in parallel universes from one fork to the next, it gets hard to keep track of your bearings.  Trello is really more of a day to day job board, I think what is needed is more of a central control panel for developers that acts as a central hub.  A single bookmarkable page that acts as a portal to everything else out there.  Forks, style guidelines, wikis, all of it.

 

[Neil Jansen]

Sorry I have a habit of jumping around in my reply and hitting 'send' with bits unfinsihed.  

On elec side I've got the impression it's not going to change and adding horse power was a hot debate. Its ok its just the opposite stage to the mech. If there we're a high level on this I think we could all vent ideas there. I would of expected the hardware to change more since we will all have PNP gear to make new idea's quicker and it's the core skill of the group

There will definitely be a higher-horsepower version down the line, but I was (and still am) very adamant that's not exactly needed now, especially since the majority of people that have reached out to me want this thing to be extremely cheap, which means that even $40 increased cost is too much.  Getting something like this under $1000 is extremely hard and when you increase the number of components on the BOM, and development time goes up when you start changing stuff that mostly works.  Our currently solution mostly works and the work needed to get it fully working is doable by a single person in a matter of hours or days.  Completely redoing PCBs, software architecture, and whatnot, will easily set us back a month and a few hundred bucks in costs to get boards made and assembled.

[Roy Nielsen]

On 12/24/2014 5:51 PM, Neil Jansen wrote:
>
> Any suggestions with where to store that or how would be appreciated.
> My preference would be somewhere central. The github wiki pages are
> sort of a mess, you end up in parallel universes from one fork to the
> next, it gets hard to keep track of your bearings. Trello is really
> more of a day to day job board, I think what is needed is more of a
> central control panel for developers that acts as a central hub. A
> single bookmarkable page that acts as a portal to everything else out
> there. Forks, style guidelines, wikis, all of it.

<suggestion>

This is why I suggested Redmine/Sourceforge/Trac - They can act as a web
portal, interface to code repository, tracking code changes to
stories/tasks/bugs/features, etc. It does the tracking for you so you
don't have to. It makes organizing
people/project/code/repository/wiki/etc/etc tons easier. Finding out
why a design/business/project decision was made is a lot easier. It's a
method of managing a project. These are the reasons I've chosen to use
these products, both at work and at home. It's made managing agile
projects much easier for me. I'm always happy to use something new -
that's why I suggested how Trello might be used.

However, I've been searching, and haven't found a place that would do
Redmine for free. In my opinion, Sourceforge isn't really up to hosting
a project like this and Track isn't as far along as Redmine.

</suggestion>

I'll be quite on the subject now.

[Jason von Nieda]

My $0.02:

Github Issues work pretty well for pretty much all of the above. The wiki is as nice or messy as you choose to make it. The issues do a really good job of referencing commits, pull requests, etc. and they can easily link to other issues. You can assign them, tag them, give them status.

Just for fun, I threw together an example to show off some of the nice features that you get for free:

A story: https://github.com/vonnieda/testing/issues/1

Note that it has several associated subtasks (which it shows the status of) and that it belongs to a Sprint (Milestone).

A milestone: https://github.com/vonnieda/testing/milestones/Sprint%201

Note that it has two stories associated and shows their status, percentage complete, etc.

The great thing about all this is that it's free and it keeps your project management in one place. I feel like it provides a lot of the functionality of Jira (which I love) for free if you just use it a bit creatively.

Jason

--

You received this message because you are subscribed to the Google Groups "FirePick" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firepick+unsubscribe@googlegroups.com.

[Paul Jones]

To be honest, I don’t really care how or where things are organised, as long as it’s done somewhere. I’m keen to get into development but I’ve been busy building my machine. I also don’t want to take on something I can’t deliver so I guess I have hesitated to volunteer so far.

I did look into making Marlin work better, but there is no reasonable way to do it. Since it works(*) I decided to leave it. I’m adding the next few parts to my machine then I’ll be on the hunt for the next task in a few weeks time.

 

Paul.

 

(*) good enough for now

 

To unsubscribe from this group and stop receiving emails from it, send an email to firepick+u...@googlegroups.com.

To post to this group, send email to fire...@googlegroups.com.
Visit this group at http://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

 

--

You received this message because you are subscribed to the Google Groups "FirePick" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firepick+u...@googlegroups.com.

[Karl]

Before we tackle project management tool choices, a consideration of goals might be worth discussing. For example, choosing one of the following would lead to different outcomes than choosing the other.

A) There is one core FPD design that is the foundation for addressing all requirements

B) FPD is a family of compatible designs that evolve together yet independently

I personally am pursuing LooseCanon in the framework of (B), since (A) is a bit too large for my head. With (B), I know what I'm doing, I have a priority list and am happily tackling that. Before I tackle something on my priority list, I simply announce it to the group, you guys comment and I adjust accordingly. For example, Paul's feedback on ABS printing was great and I amended the LC sliced pulley design. With framework (B), LooseCanon is just one emerging, self-consistent FPD build. Paul's build with his redesigned bearing block is another. Igor's build with his laser cut top is yet another. John's 3D printed top is yet another. Mike's awesome ball stud joints were adopted like wildfire. Etc. They are all equally valid peer designs. What I like about (B) is that it allows us to have separate yet synergistic goals. A laser engraving FPD and a PnP FPD can share many designs via adoption rather than by omniscient visionary planning. 

Framework (B) also introduces the consideration of self-consistent designs. This is a subtle point, and a very important one. For me it was fascinating to see how a simple change to the top plate (i.e., the manhole cover) triggered a design change of the limit switch interruptor, which needed a sharper angle to fit through the top plate hole without jamming. An LC interruptor therefore works on all FPD builds, but is required for the LC build. Framework (B) therefore naturally provides efficient progress towards individual designs at the cost of generating small compatibility issues between rapidly evolving designs.

Now, if a small group of individuals collaborates on a SPECIFIC goal (e.g., FPD 3D or FPD PnP), then that group should form its own priority list and share its vision with the rest of us as they progress towards their independent goal. In that specific context, I think each of those small working groups should feel free to choose whatever project management system they want. In other words, just self-organize to suit your shared goals.

[Roy Nielsen]

Doesn't matter to me where it's done, but I really think it needs to be done to pave the way for new contributors.

Looks like Github would be a great start.

Regards,
-Roy

To unsubscribe from this group and stop receiving emails from it, send an email to firepick+u...@googlegroups.com.

To post to this group, send email to fire...@googlegroups.com.
Visit this group at http://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "FirePick" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firepick+u...@googlegroups.com.

[Joshua Pritt]

Let's do this! Start brainstorming the tasks into a list of issues on github. I want to help on the software side. I think the actual REST endpoints still need to be developed,  right?

[Karl]

Opportunities for software involvement include:

1) OpenPnP (Jason/Neil)

2) FireSight (Karl/Simon/Neil/Armin)

3) FireREST/FireSight vision calibration (Karl)

Work on FireREST alone is somewhat problematic without an actual FPD. I suspect I'll be working with Douglas on #3, since he'll be wanting to get his machine to actually do something.

If you don't have a machine and want to work on software, FireSIght might be interesting, since Simon and Armin have both pitched in to help with FireSight without machines.

To unsubscribe from this group and stop receiving emails from it, send an email to firepick+unsubscribe@googlegroups.com.

To post to this group, send email to fire...@googlegroups.com.
Visit this group at http://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "FirePick" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firepick+unsubscribe@googlegroups.com.

To post to this group, send email to fire...@googlegroups.com.
Visit this group at http://groups.google.com/group/firepick.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "FirePick" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firepick+unsubscribe@googlegroups.com.

[Roy Nielsen]

On 12/26/2014 11:28 AM, Karl wrote:

Opportunities for software involvement include:

1) OpenPnP (Jason/Neil)

2) FireSight (Karl/Simon/Neil/Armin)

3) FireREST/FireSight vision calibration (Karl)

Work on FireREST alone is somewhat problematic without an actual FPD. I suspect I'll be working with Douglas on #3, since he'll be wanting to get his machine to actually do something.

If you don't have a machine and want to work on software, FireSIght might be interesting, since Simon and Armin have both pitched in to help with FireSight without machines.

Do we have an approximate date the beta machines might be available to purchase?  Right now, I'm more of a software guy than hardware guy, but I'd like to work towards that direction once I get a little experience with 3d printing.

I've got a Raspberry Pi & camera, I could start looking at FireSight.

Thank you,
-Roy

[Neil Jansen]

On Fri, Dec 26, 2014 at 1:54 PM, Roy Nielsen <amr...@gmail.com> wrote:

Do we have an approximate date the beta machines might be available to purchase?  Right now, I'm more of a software guy than hardware guy, but I'd like to work towards that direction once I get a little experience with 3d printing.

For anyone that can give a decent commitment that they're going to contribute to the project, I will bump them to the top of the beta test kit list, i.e. I can order parts this week or early next week, and give a pretty reasonable price that's close to my cost.  This would be the full kit including working EMC01 board, laser cut parts, 3d printed parts, extrusions, hardware, smt nozzles, 3d print hotend/extruder, etc.  Basically a working machine.  I'm putting my money where my mouth is, so to speak :)

If anyone's interested in taking me up on this offer, send me an email off-list at njan...@gmail.com, as to not further derail this thread.

-N

[Peter Shabino]

Would love to help with this but not a programmer unfortunately (well other than microcode. Do quite a bit of assembly at work for PICs and other micros). If you need hardware help let me know have a Lathe and mill on hand and half a laser cutter (next weeks project is to get it up and moving) 

Later,
Peter

My projects:
http://www.wire2wire.org/

---

Date: Fri, 26 Dec 2014 14:00:46 -0500

Subject: Re: [FirePick] Re: Marlin branches for 3D printing and OpenPnP

From: njan...@gmail.com
To: fire...@googlegroups.com

--
You received this message because you are subscribed to the Google Groups "FirePick" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firepick+u...@googlegroups.com.

[Douglas Pearless]

I am at the stage where I am going to program my EMC01 for the first time.

My first goal is to get 3D printing working so I can print out the balance of the parts for the feeders, SMT bits etc.

I saw ICEC's blog ( http://icec-blog.com/?p=94 ) about bit banging the boot loader, however I shall use a JTAG ICE MKII from Atmel (I like to be able to single step through code to help debug it :-) )

Which code base should I use:
Link: https://github.com/firepick-delta/marlin/tree/feature/3dprinting
or
Link: https://github.com/firepick-delta/Marlin/tree/dev

to get started?

Is there anything I should be aware of?

Cheers
Douglas

[ICEC]

Douglas ,

Ive used the openpnp tree
https://github.com/firepick-delta/marlin/tree/feature/openpnp

The openpnp one will  have the delta calculations happen on the host pc and openpnp(running on the host) will drive the the FDP directly (marlin taking simple gcode, no delta calcs there = faster speed)
and with the 3dprinting branch all calc will stay in the marlin firmware itself. so it can work as a standalone as the openpnp will always need to have a host pc for the calculations
 

Its not working like that yet, (delta calcs still in marlin) but thats the idea behind the split  (correct me if i wrong guys)
also the 2 use a differnt type of cordinate system ( center 0,0,0 and left corner 0.0.0)

So to get it running with openpnp thats the one needed .

As for the FT232 I used for the bootloader. it was because I had that already lying around and didnt want to buy a new JTAG if it could do the job. But other programmers should work without problems I guess .
Just make sure u are burning the right bootloader .

Anything else let me know ill try to help .

Igor

P.S.  Neil can probably explain this way better :p 

[ICEC]

after rereading you post :P
Srry

The openpnp branch is not printing any time soon , as the main focus is set on pick and placement and the feeders etc. (feeders probably dont need programming)
then I guess you should probably be needing the 3dprinting branch indeed you pointed out if its 3d printing you want to get started first

dont know if its already stable , to my last knowledge it did work but there was some wobbely strait lines , don’t know the current progress. as most of us have another printer (TAZ, Prusa etc) for printing the parts
that way we can stay focused on the PnP side of things

Karl maybe can shed some light on the 3d printing side

Igor
 
P.S. The bootloader is the same with both branches ,. boatloader is board spesific ( clockspeed etc )
after burning the bootloader , you can upload the right marlin branch (3dpringing / openpnp) with the arduino IDE tru the usb connection on the EMC.

[Douglas Pearless]

Hi Igor,

Thanks for the pointers.

I will start with the boot loader and then try to get 3d printing going.

I am talking offline with Karl about my collision issues with the current arm / spring design and need to solve that too.

Can the marlin code be compiled and debugged / modified / hacked with Amtel's studio IDE or must I use the Arduino IDE ( which I have used briefly a while time ago )?

Cheers

Douglas

Sent from my iPhone

--
You received this message because you are subscribed to a topic in the Google Groups "FirePick" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firepick/rrvXWsAfVKU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firepick+u...@googlegroups.com.

[ICEC]

Can the marlin code be compiled and debugged / modified / hacked with Amtel's studio IDE or must I use the Arduino IDE ( which I have used briefly a while time ago )?

Your welcome.

That I am not sure of as I have almost no arduino experiance before this ( was a parallax propeller guy) .
But think it should probably work, as long as the right complier is also there there should be no difference , just a personal choice of programmer

Igor

P.S. take a look in the babysteps tread, the discussion is on the calculations there too

[Douglas Pearless]

I have managed to burn the boot loader on the EMC01 (or so AVR Studio v6.2 with JTAG MKII tells me), but I cannot seem to get any response except for timeouts when I try to load a sketch to it.

I shorted out TXD and RXD and I am able to echo back terminal entries from the host so I know the RS232 interface is working.

I know the oscillator is working as I have set the fuse for the external oscillator and I can read the fuses, etc via the ISP interface.

In the bootloader.c source code it expects PB0 to be connected to a LED to indicate the status of the bootloader, but the EMC01 uses that pin, but we have PD2 as a spare/test point.

My thoughts are to recompile the boot loader and have a __FirePick_Delta__ preprocessor directive that works with the __AVR_ATmega1284P__ definition to remap the LED port, something like:

old code fragment:

#elif defined __AVR_ATmega1284P__
#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_PIN PINB
#define LED PINB0
#else

new code fragment:

#elif defined __FirePick_Delta__
#define LED_DDR DDRD
#define LED_PORT PORTD
#define LED_PIN PIND
#define LED PIND2
#elif defined __AVR_ATmega1284P__
#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_PIN PINB
#define LED PINB0
#else

Thoughts?

Perhaps I have overlooked something obvious in using the bootloader? (note: I have tried uninstalling AVR studio completely and just using the Arduino IDE, but I still get timeouts :-(

Cheers
Douglas

[Douglas Pearless]

RS232 shows my age, perhaps I should have referred to the serial port over USB 😄

[ICEC]

U sure the bootloader is burnd correctly ?

check this out ,, http://icec-blog.com/?p=94 thats how I did it ,
the commands should be the samen (if your linux)

Igor

[Douglas Pearless]

Hi Igor,

Yes I read your blog, but I have used the AVR Studio v6.2 via the ISP header and it burned and verified the file as OK.

I may try the JTAG pinning ( as the EMC01 has no stepper modules plugged in) and single step through the code.

Sent from my iPhone

--

[ICEC]

ok ok ,

Maybe try different baudrates . 115200 and 250000 .
somethimes that the thing , with lots of resetting :p


else I cant tell . all parts solderd correctly ?

Igor

[Douglas Pearless]

I have been over the soldering several times and think it is correct (I did find the caps for the crystal we not properly connected and after that I was able to burn the bootloader onto the EMC01)

Will try different baud rates, noting that I burnt the hex file “atmega1284p_16000000L_115200.hex” assuming it means 16MHz Crystal and 115200 baud serial connection?

I think the JTAG option may be best as I can single step through the code which will prove it is loaded or not!

Sent from my iPhone

[ICEC]

Yep. Nut the emc should have a 20mhz crystal. Don't know Ifor you made it yourself or got it from someone .
But I used the atmega1284p_20000000L_115200.hex one

20mhz 115200 baud

Good luck

[Douglas Pearless]

I built it myself, only had a 16MHz crystal of the correct size, have tried two of these.

Will need to either buy a fully made up board, or continue the diagnosis (will try JTAG tonight and see what happens, and try to solder in a 20MHz Crystal of I can obtain one).

[Douglas Pearless]

I have finally found the issue!!!

On the FPC-EMC01-1284.BRD design there is still and airwire connecting C3 and C11 to ground and therefore no PCB trace :-(

Put simply, with the two capacitors required for the crystal oscillator no grounded, it won't oscillate properly.

The BRD file is dated 20th November 2014.

Neil, I assume this is no longer the case with the EMC01 board?

I'd post a picture of the issue, but I am not sure how to add a PNG to a post on this forum.

Cheers
Douglas

[Neil Jansen]

Oh, wow. 

Yea, that's a real issue that needs to be fixed.  I'll need to rework the boards that I just had made.  This wasn't a problem on the first revision of boards that I had made, those worked fine and the 3-4 people that got those wouldn't have had this issue.

My apologies, and thanks to Douglas for pointing this out.  I'll try to get this update pushed to github.  In the meantime it's easy to rework with a tiny piece of 30 AWG wire-wrap wire.

--

You received this message because you are subscribed to the Google Groups "FirePick" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firepick+u...@googlegroups.com.

[Douglas Pearless]

Hi Neil,

No problem, just on of those things you get when developing stuff :-)

BTW, how do you post a picture into a post?

Cheers
Douglas

[Neil Jansen]

On Fri, Jan 16, 2015 at 11:05 PM, Douglas Pearless <douglas....@gmail.com> wrote:

Hi Neil,

No problem, just on of those things you get when developing stuff :-)

BTW, how do you post a picture into a post?

Alt-Print-screen, then Ctrl-V from gmail.  Alternatively, you can use TinyGrab to effortly host and link pictures without uploading, which I've found to be very useful: http://tinygrab.com/

[Michael Anton]

Dumb question, since I am not very familiar with Eagle, wouldn't this normally have been caught by performing a DRC after the design was done?  Every PCB package that I have ever used would have caught this.

I also see the status at the bottom left corner of the image that says "Ratsnest: 7 airwires".  Are there more unrouted traces?

Mike

[Neil Jansen]

On Fri, Jan 16, 2015 at 11:36 PM, Michael Anton <3d.m...@gmail.com> wrote:

Dumb question, since I am not very familiar with Eagle, wouldn't this normally have been caught by performing a DRC after the design was done?  Every PCB package that I have ever used would have caught this.

I also see the status at the bottom left corner of the image that says "Ratsnest: 7 airwires".  Are there more unrouted traces?

Normally yes, but this board had a few unique things that caused me to have to ignore a lot of things from the DRC (namely the combo SMT+through-hole connectors sitting on top of each other).  The other 6 airwires it's reporting aren't a problem (no electrical issues) but I'll fix them since the previous find necessitates a Revision C of the board.

[Paul Jones]

Whenever I *think* I’ve finished routing a board in eagle I do a random click around on the board with the routing tool, just to find small things like this that I’ve missed. I’m always surprised how much I miss!!

Earlier versions of eagle used to route the next nearest air wire to where you click, so if there is only one left and you click the opposite side of the board it would still try and route it. Now days there seems to be a distance limit so you have to click within a few cm for the route tool to find the air wire.

The other way to double check is turn off all view layers except air wires.

 

 

Paul.

[da...@dalewheat.com]

The first few generations of clock oscillators on the AVR chips did require capacitors for proper oscillator startup.  However, all the modern chips (generation 5 or 6 of the oscillator circuit) work just fine without them.  I've shipped thousands of AVR-based circuits with quartz crystals and no capacitors and never had any startup issues.  The stray capacitance of the IC pins + trace + crystal pins adds up to enough (5-10 pF) to do the job.

There is a great article floating around from 2005 stating, correctly at the time, that capacitors are absolutely required for reliable operation.

However, I'm happy to eat those words if you short the capacitors to ground and it starts working.  Can't argue with success!  :D

[Neil Jansen]

On Fri, Jan 16, 2015 at 10:47 PM, Douglas Pearless <douglas....@gmail.com> wrote:

Douglas, did adding the ground actually fix the issue?  Are you actually able to run arduino sketches now?

 

[Douglas Pearless]

Grounding the caps allowed the oscillator to start, i cannot load sketches, they time out.  The RXD led blinks when sending the sketch, but no TXD blinking 😞

I have written a test program to generate a square wave on one of the pins and that works properly so I know the chip works.

If I short the TXD and RXD pins I can echo back from the host terminal.

Next I will write a echo program that simply echos RXD back to TXD.

Sent from my iPhone

--

[Neil Jansen]

Try pressing the reset button right when it starts to load the sketch.  If that works, then the FT231x is unable to assert the DTR pin, which is tied to the reset pin, that most go low to start the bootload process.  My first board did that.  Still waiting to build the first Rev A to see if it does it too.  I'll know late tonight or tomorrow evening for sure.

You received this message because you are subscribed to the Google Groups "FirePick" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firepick+u...@googlegroups.com.

[A B]

If you have a way to measure frequency, I'd recommend you confirm the frequency of your square wave test.

Your symptoms also match an incorrect baud rate, which presumably could occur due to unexpected or unstable crystal frequency. (although perhaps avr uses internal rc; I'm just using other microcontroller experience for "what if" scenarios)

Another test would be to send serial data from the AVR and verify it can be received at the expected baud rate. (and received without any corruption; I.e. an endless "hello world!" stream)

Good luck,
-James

[ICEC]

Have you tried uploading the sketch bootloader style via the avr programmer pins , like burning the bootloader ?  the way I did in my blog post
compile the sketch first with the ide , figure out where it saved it , then upload it with your programmer, bootloader style

Thats how I ended up doing it, maybe thats why I didnt have that problem
I do have to admit , when I turn the my emc on , I have to connect to the emc board with pointerface first , ( and it take longer than usual.my prusa always instanly connects ) to make sure its up
after that I can start openpnp , if I just start openpnp without that , openpnp gets stuck , (maybe thats something totaly differen related , but just saying)
havent had much time running the boad yet

So I havent uploaded the sketch anytime the normal way ( IDE -- USB), only tried the avr programmer pins , but it works everytime
its a bit of a work around and needs to gets fixed, but if its work ,you know what to do

Igor

[Douglas Pearless]

Hi team,

Well this is really weird:

Here is the trace from my logic analyzer:

Which shows the reset going low and three transmissions from the Arduino 1.5 from my Mac.

There is no response!!

So it uploaded a trust "Hello World" program and it worked.

This tends to indicate that the board is wired up correctly, but the boot loader itself is not responding!

Any ideas?

Sent from my iPhone

[Douglas Pearless]

In fact here is the entire trace:

Sent from my iPhone

[Christian Lerche]

Is the DTR line wired in series with a capacitor to reset? Seems like the DTR is low, which could reset the chip all the time, so no upload is possible?

Regards,
Lerche

[Christian Lerche]