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.
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 Pin
number |
Marlin Pin
name |
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
** 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
#if (MOTHERBOARD == 81) //printrboard
#define SDSUPPORT
//comment out the following line to use onboard SD card reader
#define USESDSL
#endif
line 234:
#define ULTIMAKERCONTROLLER
Pins.h
within the Printrboard (81) section
line 953 -984:
#ifdef ULTRA_LCD
#ifdef NEWPANEL
//we have no buzzer installed
#define BEEPER -1
//LCD Pins
#define LCD_PINS_RS 41
#define LCD_PINS_ENABLE 1
#define LCD_PINS_D4 11
#define LCD_PINS_D5 9
#define LCD_PINS_D6 6
#define LCD_PINS_D7 4
//The encoder and click button
#define BTN_EN1 2 //must be a hardware interrupt pin
#define BTN_EN2 3 //must be hardware interrupt pin
#define BTN_ENC 0 //the click
//not connected to a pin currently
#define SDCARDDETECT -1
//from the same bit in the RAMPS Newpanel define
//encoder rotation values
#define encrot0 0
#define encrot1 2
#define encrot2 3
#define encrot3 1
#define BLEN_C 2
#define BLEN_B 1
#define BLEN_A 0
#endif //Newpanel
#endif //Ultipanel
#ifdef NEWPANEL
//we have no buzzer installed
#define BEEPER -1
//LCD Pins
#define LCD_PINS_RS 41
#define LCD_PINS_ENABLE 1
#define LCD_PINS_D4 11
#define LCD_PINS_D5 9
#define LCD_PINS_D6 6
#define LCD_PINS_D7 4
//The encoder and click button
#define BTN_EN1 2 //must be a hardware interrupt pin
#define BTN_EN2 3 //must be hardware interrupt pin
#define BTN_ENC 0 //the click
//not connected to a pin currently
#define SDCARDDETECT -1
//from the same bit in the RAMPS Newpanel define
//encoder rotation values
#define encrot0 0
#define encrot1 2
#define encrot2 3
#define encrot3 1
#define BLEN_C 2
#define BLEN_B 1
#define BLEN_A 0
#endif //Newpanel
#endif //Ultipanel
Sd2PinMap.h
Line 224-236
// SPI port
#if MOTHERBOARD == 81 //printrboard
#ifdef USESDSL //SDSL with Panelolu
uint8_t const SS_PIN = 40; //F2
#else
uint8_t const SS_PIN = 26; // B6
#endif
#else
uint8_t const SS_PIN = 20; // B0
#endif
uint8_t const MOSI_PIN = 22; // B2
uint8_t const MISO_PIN = 23; // B3
uint8_t const SCK_PIN = 21; // B1
To explain what the firmware changes actually do:
- Add the USESDSL define to configuration.h which allows easy toggling between the onboard SD card reader and the SDSL
- Enable the ULTIMAKERCONTROLLER which the PanelMax and Panelolu are derivatives of.
- Define the pins that are used for the Panelolu within the Printrboard section of the pins definition file
- Add a check to the SdPinMap to see if SDSL on onboard card reader is selected with the USESDSL define.
To get a Panelolu working on Printrboard:
- Confirm you can connect to the Printrboard and upload firmware - if not follow Lincomatic's instructions for loading a bootloader.
- Get Lincomatic's branch of Marlin and make the changes listed in the Firmware section above.
- Get the components required for a Panelololu and wire up the Panelolu end as described in my previous post.
- Wire up the end of the ribbon cable that is going to the Printrboard as described above.
I have a 14 pin IDC that I can use for the EXT2 header.
ReplyDeleteCould I move the LCD_PINS_ENABLE pin to a non-interrupt pin on the EXT2 header (along with the RS pin, 5v+, and ground).
Then I could use a 4 pin connector for the encoder/button/reset on EXT1 (int pins).
Would this work?
Hi, yes that would work It looks like there is clearance around the EXT2 header - the pins are shown here:
Deletehttp://reprap.org/mediawiki/images/d/d5/Printrboard_RevB_Schematic150.png
and the numbers here:
http://www.pjrc.com/teensy/pinout.html
So for example you could use PC0 and PC2 which are numbers 10 and 11.
Hi,
ReplyDeleteI 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).
However, the LCD shows 2 solid lines on lines 1 & 3. (see image)
http://i801.photobucket.com/albums/yy294/cbradburne/photo.jpg
Could you please help me find the issue with this?
Thanks,
Colin
To add...
DeleteMy 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?
Thanks,
Colin
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.
DeleteThe 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:
Deletehttp://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.
DeleteYou should be able to pop the pins out of the plugs and re-insert them in the updated locations.
Thanks so much for helping with this.
ReplyDeleteChanging the pins has made a big difference, there are characters now! Just not the right ones ;)
I've uploaded another picture:
http://i801.photobucket.com/albums/yy294/cbradburne/photo-1.jpg
The screen is blank to start with until I start pushing and turning the encoder.
hi Colin can you email your marlin setup to me (email address availabe if you click on my name on this post). the files I really need are the pins.h and configuration.h
DeleteHi,
ReplyDeleteJust thought I'd post to say I now have this working great with a Printrboard.
Proof ;) :
http://i801.photobucket.com/albums/yy294/cbradburne/photo-1-1.jpg
Tony, thanks for all your help!
Great!
DeleteThis comment has been removed by a blog administrator.
ReplyDeletehi can any one help me i have followed the instructions but i cant get any image from the screen its just blue
ReplyDeletehi,
ReplyDeletei 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)
thanks in advance
wasty
Printrboard issues
ReplyDeleteOne 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.
I managed to get it connected to my printrboard and it works.
ReplyDeleteBut 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?
Hi Tim
DeleteGreat to hear its working well.
to answer your question about saving the settings it sounds like you may still have the
#define EEPROM_SETTINGS
line 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_CHITCHAT
in configuration.h as well
Tony
Excellent article!
ReplyDeleteI'm trying to do the same with my graphics LCD controller
http://prepare-blog.blogspot.de/2013/05/pcb-prototyping-for-my-indiegogo.html
Do you allow me to use your picture of the printrboard PCB for the illustration of the pins necessary for my controller?
Hi Dirk
DeleteYou 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?
Cheers
Tony
Hi !
ReplyDeleteI2C is freeing 2 GPIOs could be an option. Up to now i haven't scannde the market for GLCDs with I2C interface.
I'll put a reference to your document in my blog article.
Regards,
Dirk
Hi
ReplyDeleteI 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.
Hi Michael
DeleteI did the original testing with a Rev D board so that should be fine.
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
Cheers
Tony
Hi Tony
DeleteI 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.
//LCD and SD support
#define ULTRA_LCD //general lcd support, also 16x2
#define SDSUPPORT // Enable SD Card Support in Hardware Console
#define ULTIPANEL
#ifdef ULTIPANEL
#define NEWPANEL //enable this if you have a click-encoder panel
#define SDSUPPORT
#define ULTRA_LCD
#define LCD_WIDTH 20
#define LCD_HEIGHT 4
// Preheat Constants
#define PLA_PREHEAT_HOTEND_TEMP 180
#define PLA_PREHEAT_HPB_TEMP 70
#define PLA_PREHEAT_FAN_SPEED 255 // Insert Value between 0 and 255
#define ABS_PREHEAT_HOTEND_TEMP 240
#define ABS_PREHEAT_HPB_TEMP 100
#define ABS_PREHEAT_FAN_SPEED 255 // Insert Value between 0 and 255
#else //no panel but just lcd
#ifdef ULTRA_LCD
#define LCD_WIDTH 16
#define LCD_HEIGHT 2
#endif
#endif
Is my firmware too old?
Tony
DeleteI 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...
ReplyDeleteAny 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.
Hi
DeleteUnusual 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?
Cheers
Tony
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.
DeleteI 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.
Hi
DeleteGreat detail there!
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.
Cheers
Tony
also to avoid confusion this discussion is about an weird thing going on with a Panelolu2... not an original Panelolu!
DeleteCorrect 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.
DeleteSo 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...
Deletein UltraLCD.cpp:
Original Code:
#define ENCODER_STEPS_PER_MENU_ITEM 5
Change to:
#define ENCODER_STEPS_PER_MENU_ITEM 2
Original Code:
#ifdef ULTIPANEL
if (encoderDiff)
{
lcdDrawUpdate = 1;
encoderPosition += encoderDiff;
encoderDiff = 0;
timeoutToStatus = millis() + LCD_TIMEOUT_TO_STATUS;
}
Change to:
#ifdef ULTIPANEL
if (encoderDiff)
{
lcdDrawUpdate = 1;
encoderPosition += encoderDiff / 2;
encoderDiff = 0;
timeoutToStatus = millis() + LCD_TIMEOUT_TO_STATUS;
}
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:)
Hey
DeleteGood 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.
Cheers
Tony
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.
DeleteBut here's to not having to kick myself in the head anymore.
Thanks for the help.
Andrew
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.
ReplyDeleteAnd 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.
ReplyDeleteIf 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.
ReplyDeleteHi,
ReplyDeleteNice 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.
Thanks for your help
Hussain
Hi Hussain
DeleteIt has been ages since I last looked at Marlin so I don't know which of the branches supports I2C displays and CoreXY.
sorry I can't be of more help but I have not kept up with that as everything is focused on RepRapFirmware on Duet now.
Cheers
Tony