Papilio 3d printer firmware ideas

[nilrods]

I got my Papilio DUO the other day and have been playing around with. Let me say I really like what I see. I only had a couple issues(drivers but got fixed), less than most development boards I have used.

 

My main project for buying the DUO was for 3d printing. As I mentioned in an my intro post I think the DUO is a great platform for this.

 

I have started working on splitting up the Teacup firmware for arduino. I put together a small document with my ideas on how a 3d printing firmware might work on the DUO. Looking for others thoughts especially on the FPGA side of things as I am just starting out learning that side. Feel free to chime in on any thoughts.

 

I broke it down into 2 phases just to make the coding a little easier on my end. The 1st phase is just moving all the motion planning and control over to the ZPUino. The later phase will be the better stuff, moving the stepper control out of the ZPUino and just plain fpga, but leaving the motion planning on the ZPUino.

 

One of the areas I am especially looking for some input is how to bridge the atmega32U4 to the ZPUino. I need to send data (positions for each axis, estop, etc) to the ZPUino and possibly request data in return (current position) from also. My first thought is something like SPI or I2C over some of the shared pins. I would love to hear if there are some easier or faster or more efficient approaches. Another item I am looking for some feedback is in the Phase 2 area. I showed two possible configuration for how I think it might be done. Any feedback on those would be appreciated also.

 

Chris

papilio_3d_firmware_ideas.pdf

[Jack Gassett]

Hello Chris,

 

This is great, I'm planning on leaving for a week long road trip tomorrow so I will be limited in what I can do. So I wanted to get a quick response in between preparations for the trip tonight.

 

I think what you need for the communication between the atmega32U4 and the ZPUino is already in place. Alvie made a nice AVR to Wishbone bridge that can do what you are looking for. If you look at File/Examples/AVR_Wishbone_Bridge you will find an example. Also, the AVR Wishbone bridge is built into all instances of the ZPUino for the Papilio DUO. 

 

For the stepper controller, we already have a basic one that works with zpuino. I'm attaching it here, the next step is that we just need to convert it to a DesignLab library and add any additional functionality that you need.

 

Jack.

papilio_stepper.zip

[nilrods]

Jack

Great stuff thanks. No worries, I am just getting started so I have plenty to work on right now.

 

I saw the AVR to wishbone one, for some reason I was thinking it was just for the AVR8 and ZPUino softcores. I'll take a look at that, if that will work that is awesome.

 

Thanks for the stepper files too. I saw the vhd out there in one of the repositories but couldn't find an example of using it from the arduino side. I think the ones I found was old because it referenced a header file on the arduino side. I will look this one over also.

 

Thanks,
Chris

[nilrods]

Jack,

The more I learn about the papilio the more I think it is a great idea and has lots of potential down the line.

 

I took a look at the stepper library. Looks like it would work great for running a stepper in velocity mode, like a rc car or such. 

 

I did see a couple concerns with running in more of a multi-axis positioning mode though. I saw the interrupt code to change speed and all. Imagine though a 3d printer or CNC machine with 4 or 5 or even 6 axis(steppers)running simultaneously. I could see 3 or more axis all interrupting at almost the same time and if those interrupts weren't serviced in a timely fashion the stepper could overshoot the requested position or even worse one gets missed. This could be bad and result in at least an overrun in position or worse case a runaway axis.

 

Based on those thoughts, I took a stab at adding some code to the library. Basically I added an option to the control register that can enable this mode, but still defaults to the original mode you wrote. The option basically turns off step generation after the requested number of steps have been done. Then when a new set of steps are added it resets the registers and starts generating again. The two modes can still be mixed also. The sim.png shows 2 position step cycles and a velocity cycle. I also added the newer 2 signal wishbone instead of the older multi-signal one.

 

This is my first attempt at writing any vhdl other than tutorials so any feedback on how I did it bad or good is appreciated. It is probably pretty hack since I come from a software background. I also added a bunch of comments to it based on some old docs for the stepper library I found. It was a great exercise in learning vhdl though.  I tried to create it as a papilio library but could not for the life of me figure how to modify the example library to do anything other than what it was written to do. Are there any videos on creating a papilio library, I couldn't find one?

 

Also I looked at the avr to wishbone bridge. I think that will be great for when the avr needs to talk to the hardware. I could not figure out how it would help the avr talk to zpuino though, since I couldn't find what wishbone address the zpuino itself was, only things attached to the zpuino.

 

The avr to wishbone bridge also doesn't synthesize as is, the attached error is thrown. I even tried to update the code to match the count listed in the error, but that just generated a different error about multiples. I assume there has been some change possibly to zpuino structure that may be causing this.

 

 

Anyway I figure you probably still out on vaca, but thought I would share my findings. Will continue to work on the project.

 

Thanks,

Chris

 

crstepper.zip

[foft]

Just a thought on avr- wishbone and zpu- wishbone. It's prettty normal on multiprocessor systems to have communication via slaves on the bus rather than CPU-CPU comms.. Eg they could both write to memory or a custom slave. I guess wishbone has some arbitration to choose between multiple masters. Be careful of race conditions!

[nilrods]

Foft,

That is an idea. I understand your thinking. I was kind of wondering the same thing. I just wasn't sure of the architecture of the design and how it was meant to allow the avr and zpuino to talk. I would think there would still need to be some sort of signaling between the 2 but maybe the wishbone will handle that, i.e. avr wrote something to memory that zpuino needs to read and vice versa. Then again I way outside of my area of expertise so I could be way off here.

 

Thanks,

Chris

[Jack Gassett]

Hey guys,

 

Back from vacation today and just catching up with all the forum stuff. Got a lot to catch up on, so probably can't get into too many nitty gritty details for this today. Congratulations on the changes to the VHDL code you made. Sounds like it simulated properly and so should most likely work in real life. As far as turning it into a Wishbone library. I was working with someone before vacation on just that task and realized I need to get some more work done and write some tutorials to help make it clearer.

 

As far as the AVR-Wishbone bridge goes I'm thinking you will make a Wishbone component that is basically just some registers. The AVR can write to those registers and the ZPUino can read from them and vice versa, both the AVR and ZPUino act as Wishbone masters...

 It would be a good start and then we can expand for whatever else we need it to do such as interrupts.

 

Jack.

[nilrods]

Jack,

Hope the vaca was good. Ok I will hold off trying to create the designlab library for it.

 

That makes more sense now on the avr to wishbone bridge. I wasn't exactly sure how the 2 were designed to communicate over the bridge. I will give that a shot at creating.

 

I have most of the arduino code for the firmware modified to run just that portion on the avr side, just need to tie to the bridge when I get that piece done. The motion control code on the zpuino side will take quite a bit more work to separate from the rest of the firmware.

 

Thanks,

Chris

[nilrods]

Jack,

I saw you added some videos for building the library. I will take a look at them and give building and posting the stepper library a try.

 

Also I saw there is a new 1.5 of designlab. I was working with 1.4 of designLab. Do you think the error I referred to earlier in this thread with the avr_to_wishbone bridge might be fixed in this latest version?

 

I am also working on a canbus library which I will also upload once I get it working. Of course, canbus is used in cars, but also being used in many smart servo and stepper drivers these days. Of course, using the canbus does require a separate transceiver I believe.

 

Work on the zpuino side of the 3d printer firmware continues.

 

Do you know if the vanilla zpuino in designlab uses arduino libraries for math functions, like sin, cos, square root or is there something like a cordic on the fpga behind the scenes doing the heavy lifting? Just wondering because for my motion controller algorithms being able to use those would probably really speed things up and make more accurate. If not, that is ok also the current avr code works but has some work arounds because those functions are costly on avr.

 

Thanks,
Chris