Sunday, 22 July 2012

Panelolu with Printrboard

Panelolu with Printrboard

Update: The Panelolu2 has replaced the Panelolu. It is much quicker to install, has adapter boards to no messing with cables and uses less pins. The blog post with the information is here, it is available to buy in our webshop.The Printrboard is a based on the Teensylu which is itself a derivative of the Sanguinololu; the main difference is the use of the AT90USB1286 in place of the ATmega644P or 1284P.

Thanks to the work of Lincomatic, Marlin firmware will run on the AT90USB1286. The Printrboard section of the RepRap wiki page has information on the board and an outline of how to upload the firmware - you will need Lincomatic's fork of Marlin. The Printrboard I bought was supposed to come with a bootloader but that did not work. I followed Lincomatic's instructions to install the CDC bootloader using the Pololu ISP I have used previously on ATmega644P and ATmega1284P micros. It's worth ensuring you have a working setup with the Printrboard connecting to your control software (Pronterface for me) and firmware uploading before you go any further.

Built in SD card reader or SDSL?

The Printrboard has a build in SD card reader so you do not need an SDSL. That said I prefer to have the electronics hidden away, so using the SDSL in the Panelolu is my preference. Both options will work and are described below.

Hardware and wiring the Panelolu

The wiring internal to the Panelolu is identical to that described in my previous post, with the option not to bother with wires 13,15,16,17,19,20,21,22 and the 10 pin IDC connector if you are going to use the build in SD card reader on the Printrboard.

Unfortunately the design of the expansion headers on the Printrboard does not keep to the standard 2.54mm spacing between the expansion header and the ISP header (and 4 pins on ext1 are not I/O by default) - a simple IDC connector will not fit without bending the pins . The solution is to use the same connectors that are used on the LCD and circuit board within the Panelolu.

The pin out is as follows:

Ribbon cable wire
number

Printrboard Pin
Label

Marlin Pinnumber

Marlin Pinname

1

Not used *

---

---

2

Not used *

---

---

3

GND

---

---

4

5V

---

---

5

PD4

4

LCD_PINS_D7

6

A3

41

LCD_PINS_RS

7

PD6

6

LCD_PINS_D6

8

TX1

2

ENC1

9

PE1

9

LCD_PINS_D5

10

RX1

3

ENC2

11

PC1

11

LCD_PINS_D4

12

SDA

1

LCD_PINS_ENABLE

13

A2***

40

SDSS

14

SCL

0

18

RESET**

---

---

* Wire 1 and 2 are not connected/used but kept in for consistency with the original instructions.
** Can come either from the RESET pin on the expansion header or the ISP header.*** Only required if a SDSL is used rather than the on board SD card reader

Update There was a mistake in the table above, thanks to Colin Bradburne for bringing the problem to my attention. It is fixed now - the lines in red have been amended.

If using the SDSL rather than the on board SD card reader then the following connections to the ISP header are used as well.

Ribbon cable wire
number

Printrboard Pin
Label

Marlin Pin number

Marlin Pin name

17

GND

---

---

18

RESET

---

---

19

MOSI

22

MOSI_PIN

20

SCLK

21

SCK_PIN

21

5V

---

---

22

MISO

23

MISO_PIN

The Printrboard I bought does not have the expansion header pins labelled, I have annotated the pins on the screen shot of the board below:

The 4 pins labelled "JTAG PINS" are set to the JTAG interface by default - I have done a separate blog post about how to change the fuse settings to gain access to these pins as I/O. This does mean that we can't fit the Panelolu connections onto just one expansion header, hence the 4 pins on the second expansion header towards the centre of the board

The ribbon cable with the connectors will look like this:

Pairing this picture with the annotated screen shot of the board should show how to plug in the cables. (note that wire 1 and 2 are not in this picture as they are not used and that a 4 pin connector is used for MISO,SCLK and RESET because I ran out of 3 pin connectors)

Firmware configuration

The following firmware changes to Marlin are required to get the Panelolu working with a Printrboard. Please note that line numbers are based on my version of Lincomatic's branch of Marlin - they may be slightly different with a different version or after additional changes are made.

Configuration.h

line 34-40:

#define MOTHERBOARD 81

#if (MOTHERBOARD == 81) //printrboard #define SDSUPPORT //comment out the following line to use onboard SD card reader#define USESDSL#endif

Hi, yes that would work It looks like there is clearance around the EXT2 header - the pins are shown here:http://reprap.org/mediawiki/images/d/d5/Printrboard_RevB_Schematic150.pngand the numbers here:http://www.pjrc.com/teensy/pinout.html

I recently received a Panelolu from you with the intension of using it with a Printrboard. I've connected the wires (triple checked, including a continuity test), changed and uploaded the firmware (confirmed by altering the version string).

My Printrboard isn't connected to anything else other than the computer via USB (for power) and the Panelolu. I see you have a connector plugged into the hot end thermistor, must I have a thermistor connected for the board to work correctly?

The Marlin firmware goes into "fail-safe mode" if there is no thermistor connected to the T-EXT port. I know pronterface locks up and gets flooded with error messages if the thermistor is not connected. I suspect the LCD doesn't get updated in this mode.

The Panelolou should operate without thermistors etc plugged in. I had a resistor attached to give a hotend temperature reading but that is not required - I have mine sat here with nothing other than the Panelolu plugged in now and the display is fine. There have been a few reports of the board locking up if the endstops are not set correctly, see the comments in here:http://blog.lincomatic.com/?p=537

Ok I checked through the pin-wire table above and realised there was an error there, the corrections are in red. Originally I wired this up differently within the Panelolu when I thought I could still use one IDC connector. Once the pin spacing and the JTAG issue came to light I changed it to have the same wiring within the Panelolu and deal with the differences at the board end of the cable.

You should be able to pop the pins out of the plugs and re-insert them in the updated locations.

hi,i did it, and my displays is lighting blue. But i cannot generate a working firmware.I just did what you wrote, but i cannot connect in pronterface anymore with my firmware.Could you post your 3 files please?! It would be veeeery helpful!or could you email them to me? (pb.20.dsa@spamgourmet.com)

One of our customers highlighted an issue with the Printrboard design: the Y-endstop is on the SS pin. The solution is on Colin Bradburne's blog (http://my3dprinterbuild.wordpress.com/2012/09/02/printrboard-sd-card-boot-up-fix/) which I wont repeat here but if you are intending on using an SD card with Printrboard it is well worth reading his blog.

But I had some issues; first the screen only showed blocks no text, I solved this by removing the already existing ULTRA_LCD define in the printrboard code block.I first only added the code from this blog without removing the old one.. since the line numbers are a bit off.

I also changed the Y-MIN pin to 37 and replaced the connector to the extra sensor connector on the printrboard so i could use the onboard sdcard. I'm not sure if this is necessary with the lincomatic code. But it was in my old firmware.

I'm very pleased with the result, it works like a charm now, only using the print from sd function now with the lcd attached :)

One thing tho, if i change settings on the display and choose 'store to memory' it's not really saved after a powerdown. Is this something i can enable?

to answer your question about saving the settings it sounds like you may still have the#define EEPROM_SETTINGSline commented out in configuration.h, if so uncomment it.

You can test these using the following codes through pronterface or whatever computer software you use to connect you your printrboard:

// M500 - stores paramters in EEPROM// M501 - reads parameters from EEPROM (if you need reset them after you changed them temporarily).// M502 - reverts to the default "factory settings". You still need to store them in EEPROM afterwards if you want to.// M503 - print the current settings (from memory not from eeprom)

In order to get a meaningful response from Marlin and check these commands are working quickly make sure you uncomment:#define EEPROM_CHITCHATin configuration.h as well

You are free to use anything on the blog that Think3DPrint3D has created - its all licensed under CC BY SA (Creative Commons - Attribution - Share Alike). To give attribution a link back to this blog would be great.

I like the Graphics LCD - are you planning on implementing an I2C version?

I have the panelolu I got back in December of last year. I've got it all cabled out just like the directions here attached to my Printrboard. I have a Rev D board. Is that what is used here? are they all pinned out the same? I've triple checked all of the wiring yet all I get are two rows of bars on the LCD. The only thing so far that works is the reset. lol.

Will the latest Marlin work with this? I've checked it out with Git and uploaded it to the board after making the mods listed here.

Any input on diagnosing what is going wrong would be greatly appreciated.

The issue is probably firmware related if you have double checked the cabling - are you using EXT2 or have you disabled JTAG?

When I wrote this the only branch of Marlin that was proven to work with Printrboard was Lincomatic's branch. Since then Marlin has progressed a long way and printrboard is supported as standard. What I don't have the ability to do is test the original Panelolu with every electronics each time Marlin is updated (daily!). I suggest you try with the changes above with Lincomatic's branch linked above to prove your hardware setup and cabling - first prove it works in general and you can control the printer in pronterface or your host software of choice, then enable the LCD as described above

I am using EXT2. THe version of Marlin I have is the one the vendor supplied with the card. In one part there is the addition of #define ULTIMAKERCONTROLLER. In my firmware source there is no mention of this. Here is what my configuration.h has in it.

I tried to do some experimentation with the firmware version. I grabbed the latest Marlin and made the changes and now I have characters on the LCD. It looks normal except the rotary encoder is not being recognized. Any suggestions there?

I have a panelolu hooked up to a Solidoodle 3. It has worked for quite some time, but I noticed the other day that my feed rate crept up slowly over time without touching the encoder knob. EG on a 1:40 print it started at 100% and ended at 239%. Obviously this is no bueno. Anyhow I did accidentally plug in the header incorrectly to my Sanguino board when I had pulled my machine apart for some other task. It ended up messing up an SD card, but other then that I "thought" everything else is fine. Apparently not... Anyhow I'm handy with a soldering iron, and have some basic circuit board skills, testing, building, etc...

Any advice on how to fix this would be much appreciated. Not sure how the encoder would have got messed up, but maybe it's the IC on the board, a pin slightly fried, or something... I don't know. Anyhow I'd really appreciate help troubleshooting this so I can get back to work.

Unusual problem, one I have not seen before so I need a bit more information:

when you plugged the adapter board in wrong do you think you got 12V into the 5V circuity on the Panelolu2? that could have messed the level shifter for the SD - is that permanently broken now?

As the I2C IC on the expansion board is still working (the LCD still works I assume) then it is unlikely this is damaged, also the encoder channels do not go via this IC by default (see the detailed description and circuit diagrams here: http://blog.think3dprint3d.com/2013/02/panelolu2.html). does the value increment happen regularly or at random and how much does it increment at a time?

Hey, thanks for the help. It is possible 12V got into the Panelolu 5 V circuitry. My sd card was dead after the incident, and I am assuming that was teh culprit, however I put a new sd card in and everything works fine in that regards. So seems like nothing permanent there except a dead SD card.

I have been doing lots more testing. I have found that the creep only happens when I turn on the heated print bed on. (my printer is a Solidoodle 3) Otherwise no creep whatsoever, except that when the panelolu boots up it defaults to a 99% feed rate as opposed to 100%.

I reflashed my firware multiple times to make sure nothing got corrupted on the Sanguino end.

It does seem to be a somewhat consistent increment over time, at least as far as the time increment is concerned, as far as the feed rate incrementing up it seems to do it 1% at a time.

I started to be suspicious I caused some degradation in what I thought was the hardware debouncing circuit for the rotary encoder on the Panelolu board. When I measured voltage with probes on the ground coming off the encoder, and on the AB outputs right before they go into the MCP23017 (and according to the schematic converge) I would detect a consistent voltage drop from 2.34V to 2.33 volts whenever the print bed heater was turned on, which would not be present and completely rock solid 2.34V reading when the heated print bed was not turned on. Although perhaps this is normal, and irrelevant.

Being suspicious of a debouncing issue I attempted to implement some software debouncing in Marlin in the ULTRALCD.cpp file. Not being a master programmer by any stretch I implemented the changes documented on this forum thread to reduce the sensitivity of the rotary encoder. Which actually had the side affect of fixing the panelolu booting up with a default 99% feedrate. Now boots up to the default 100%. Also it caused the creep to happen much more slowly... but that seems to correlate with the decrease in rotary sensitivity...

Here is a link to the thread I followed for those marlin changes above to ultralcd.cpp: http://forums.reprap.org/read.php?146,195427,195427

Also I posted here on soliforum.com:http://www.soliforum.com/topic/3876/my-panelolu-feed-rate-steadily-creeps-up/

Another fellow user who goes by lawsy, who also helped develop the Marlin code that Solidoodle uses as there standard default firmware they load on their sanguino boards. He also reported experiencing a similair issue with his panelolu board over time. his solution was a gcode change in Sli3er that caused the printer to reset it's feedrate back to 100% after each level was finished printing.

Of course that is a temporary work around since it makes on the fly feedrate adjustment pointless.

So that is where I am at so far. Trying to get my programming skills up to snuff so I can implement some debouncing for the encoder to see if that remedies the problem.

Sorry to shotgun you with a spray of what I have done. Just really miss printing from SD:) by the way great work with the board, and what not. It has made my Solidoodle everything I wished it was.

Firstly I need to emphasize that unless you are using the Panelolu 2 in the non standard way , it is a direct connection from the pins of the encoder into the Sanguinololu board and to the pins of the Atmega 1284P. I did design in the provision of sending these via the I2C circuit but did not go with this in the end due to the additional overhead in incurred in processing in the firmware, it was not a good idea with the current MCUs. Where they converge in the schematic is a solder jumper to allow for either routing into the MCP23017 or directly, direct is the default.

Secondly I don't think it is a debouncing circuit issue as there is none, the encoder pins are connected directly to the MCU pins and rely on the hardware pins being slow enough to react along with software debouncing that is built in to the Ultimaker controller original code with the encoder reading logic. It could be a noise related problem but it seems odd that you get a consistent increment if it was noise related.

The fact that the heated bed makes a difference is interesting, as you note the voltage level varies based on if the heated bed is on or not. can you confirm if the problem is any different if you have another source of 5V applied (ie the usb cable plugged into your PC).

I am a short distance away from suggesting you contact us directly about returning your board for testing/replacement.

Correct it is a panelolu 2 that I am using. Ok, good to know there is no hardware debouncing on the panelolu 2. Also verified that the problem does persist even when an independent 5 volt source is plugged in via usb. Could this be a bad encoder? Well anyhow such a weird problem. If there is a way for me to increase the debouncing in the marlin firmware and you could direct me to the lines of code I need to change, I'd gladly just as well do that. But getting a replacement would be of course acceptable. Just would prefer the quickest method of course, and I really don't mind altering my firmware, I'm very comfortable with that.

So here is some hopeful good news. I believe I found the magic bullet for a firmware fix for this problem, and at the same time it allows for better precision when dialing in the feedrate to exact percentages...

Not exactly sure why this works, I can only theorize it adds a little extra layer of debouncing to the rotary encoder implementation in the firmware. All I know is I couldn't get my print bed to heat up to more then 30C before the creep would come on in.

So far I have reached full temp, and no signs of the feedrate creep. Plus it's a little easier to adjust now.

Anyhow I'll of course need to run a print of some length to see if it really is the silver bullet. but so far, I am feeling much better:)

Good discovery, I think its masking the issue by reducing the sensitivity so the encoder needs to have moved two points before anything is registered. I wonder if your setup is allowing a lot of noise onto the encoder lines.

Right, I agree it's just masking the issue. But I am more then happy to live on in ignorance if it keeps working:) I would not be suprized, solidoodle has been notorious for many, many, many less then ideal designs.... they really are more like pre-assembled kits that will need tweaking, overhauling, etc... before they are useable without wanting to kick yourself in the head.

I have a Printrboard rev D in a Solidoodle 3, and I have been having very problem imaginable. First, newest Marlin has messed up the pin numbering between pins.h and SD2pinmap and fastio. Second, HID bootloader does not take firmware sizes bigger than 100K. I flash CDC bootloader with usbtiny, fix pin numbering and load in the sd support and LCD. I cannot get an external SD port working. Not with a reprap smart kit or SD ramps. I configure for built-in and I can read the card. I connect to the printer and find I need to relocate the Y endstop. I get all of this done, and finally select a simple 10mm cube gcode I built in repetier, and the print freezes on the third layer. Consistently. I try another gcode, and it freezes on the first layer. When it freezes, the heaters stay on, controls and usb connection is non-responsive. I could not mind getting any insight you might have.

And now the plot thickens....I hooked everything up to a cheap printrboard clone (this required alot of connector rework as Solidoodles polarized headers are all backwards) and low and behold I was able to print out my test gcode. It came out funky as I did not spend time adjusting the current limits on the stepper drivers, but it made it through the entire print without freezing. So now it looks like the firmware is not the suspect, but the original motherboard from SD. Ugg. The layout files all match. I guess I should check the SD interface IC to see if there is a difference. Also, I was able to get the clone board to talk to a SD RAMPS board. I wish I knew what the hell the difference is here.

If I upload marlin firmware with comment out line #define panelolu2 and I am not plug in the panelolu2 LCD in printrboard then my printer is not connected with prontrface. please help me to solve this issue.

Nice article, I did follow the instructions as above but am running into a few issues, if I comment out #define panelolu2 the program does not compile and starts giving errors. Could you suggest the version of marlin that I must use to ?

Also am building a corexy printer so the marlin firmware should have the core xy kinematics on it.