Printer stopped due to errors. Fix the error and use M999 to restart. (Temperature is reset. Set it after restarting)>>>m999SENDING:M999Resend: 1Error:2: Extruder switched off. MINTEMP triggered !Error:Printer stopped due to errors. Fix the error and use M999 to restart. (Temperature is reset. Set it after restarting)

If I plug in the LCD, the com port and connection disappear.

If I unplug the LCD and/or Extrudrboard the bot works as expected (though I haven't put it through a full regression test. Everything obvious works.)

I've watched Brook's video of setting these up and am following his pin connections. I've got a second PSU powering the Extrudrboard per spec.

Anyone have this working? Did it just work or did you have to do anything special?

0

Last edited by Tdeagan on 2013-Sep-Mon-19-Sep, edited 1 time in total.

Interesting. A thermistor into the third extruder plug? I have my second extruder/heater/thermistor plugged into the first of the two connections (aka the second extruder connection set,) but nothing else but power and the ribbon cable.

Are there docs that describe the additional thermistor you're noting? Does it go into the 3rd thermistor socket? It's a two wire connection so it's hard to picture it going into the motor plug.

Ya it goes into the 3rd extruders thermisister plug. Otherwise it tripps out and gives warnings. I believe Printrbot is going to add it to the kit. I know for the dual extruder kit production version not beta. It will be included and I would also assume it would be added to the extrdrboard kit as well.

I watched most of the second video (the parts that seemed relevant to just the Extrudrboard and LCD, but not the Printrbot stock extruder kit.). But I didn't watch the other two.

I get really impatient watching videos. They're so linear. My learning style betrays me with them. I can spend untold hours combing data sheets or reading manuals or web material, but watching a 3 minute video just kills me. I've been trying to learn Blender, but all the tutorials are videos and its like pulling teeth to sit through them. They're clearly where the world is going. Sigh.

I burned the specific firmware (Printrbot-LCD-Extrudr-Firmware) in case the latest Marlin I was using was wrong.

I'm still struggling with a critical work/no-work app note like the third thermistor thing being tacked onto the end of a video. I only stumbled across those vids, it's not like they were listed on the product page as required. Seems like that would be something you would note on the product page or in a tech note sent with the product. Whatever.

I don't have a third thermistor (I've been a thermocouple guy up to now.) But it seems like a standard resistor would fulfill the same purpose. My intertoob search says it's an EPCOS 100k NTP thermistor, which suggests that I could use a 100K resistor across the third thermistor port.

Either way, attaching my LCD still causes the system to drop the com connection, so something is not right there.

I'll try out the dummy load on the third thermistor port and report back.

Ya I agree with you. Supposedly the recent changes Printrbot has made is to get a handle on this sort of stuff. So hopefully they do. Thats a big reason for my blog, is to attempt to help and clear up as much confusion as possible.

I whipped up a 100K Ohm resistor with the proper plug and plugged it into the third thermistor port. I still couldn't get the Extrudrboard to work.

I compiled and flashed the latest Marlin firmware, it's more recent than the special LCD/Extrudrboard version, says it supports the LCD and I wanted source.

I removed the dummy load and, for lack of a better term, 'fiddled' with the Extrudrboard, watching the VDC output of the heater (with Pronterface trying to set the T1 hotend to 185C.) And it started working.

So now, I have the Extrudrboard working, pushing my #2 (T1) extruder with nothing plugged into the third thermistor port.

However, if I connect the LCD, the Printrboard goes offline and won't provide a USB connection.

I dont have the most recent firmware. I have the one that says something like dual e /lcd hex. They may have fixed the issue. They really need to get a quality guide figured as well as a dedicated firmware guy just for pb on mac and Windows. Too confusing

I just traced every pin on the LCD and there aren't any shorts. It's a _very_ simple board and I'm really familiar with the standard 16x2 LCD.

When I plug it in, the backlight comes on, Row 0 and Row 2 go solid black. The printrboard loses it's ability to provide a COM port. It's kinda acting like it's drawing too much power, but I pushed the RAMPS 1.4, 2 ABS heated extruders and a bed at 100C plus the LCD controller off a single 350W power supply. Now I've got an additional supply, so I'm highly skeptical that this little LCD is pulling too much current without a short.

I have noticed that the Firmware has some odd pin assignments. Here's the section from the latest Marlin Printrbot firmware for the Printrboard:

The Printrboard schematics show that the connections are to the following pins on the at90usb1286:RS 34ENABLE 33D4 32D5 31D6 30D7 29

EN1 35EN2 36ENC 37 //the click

There must be some abstraction/redefinition going on someplace that I'm missing. But incorrect pin assignments could cause very similar symptoms. It would put it right on top of the USB pins of the aat90usb1286.

The other pin assignments for things that are working don't map to the actual at90usb1286 pins.

Tdeagan wrote:There must be some abstraction/redefinition going on someplace that I'm missing.

Yes, I ran into that - and set it aside for later deep study.

In my case, I was wanting to remap the Z motor output to different pins in order to use one of the headers on the Prinrboard. But when I traced through config.h to what the existing pin assignments were, there was no correlation to the physical pins on the Atmel chip. And in the case of the motor control pins, there was not even the mapping of Port X Bit y... Totally confusing. Lwalkera or Pxt (I forget which) explained that the Arduino ecosystem uses an arbitrary higher-level pin mapping to make it "hardware agnostic." But then there's a confounding factor of the "fastio" add-on which apparently re-maps again. So you've got to have a pretty high tolerance for intricate mapping, and you've got to be able to track down documentation resources (pin mappings) that I can't for the life of me find anywhere.

Good luck, my friend! If you find the magic table (tables) of mappings, please share them on this forum.

This is convoluted stuff. I spend much of my work-life futzing with issues like this. A few choice blog posts/notices on the Printrbot website would go a long way to clearing things up.

There are a couple contributing problems, the first of which is the number of places that state something like"This version is for supporting Printrboard The copy at https://github.com/PxT/Marlin is the official source as shipped by Printrbot HQ."

That may have been true at a point in the past, but is (apparently) no longer accurate. In his videos, Brooks is promoting https://github.com/Printrbot as the official site.

The Marlin code has a gazillion forks. This is the network chart of the Printrbot site's code: https://github.com/Printrbot/Marlin/network You can see the fork by PxT a little ways down and by scrolling around you can see that PxT had commits as late as June 4 that haven't been committed to the Printrbot fork.

Both PxT and Printrbot were forked from Lincomatic which was forked from ErikZalm which is the top of the network (his network graph show the terrifying number of forks out there for the unwary.)

The USB connection disappearing is more a result of Brook just ordering the cheapest LCD he could find, not checking the specs, and ending up with 3.3V LCDs. Fortunately, the only thing different is the value of the current limiting resistor for the backlight. You can disconnect LCD backlight and stop the overheating and browning out by unsoldering the solder jumper on the back of the LCD to the right(when the front is facing you) of the pin header.

This kind of stuff really needs to be caught early on or at least have a page with workflow notations as far as what happened, how it was fixed etc. I am a die hard Printrbot guy all the way but, if this kind of issues aren't figured out soon I feel that a lot of people will go somewhere else. Printrbot says they are going towards a more user friendly bot so I guess only time will tell. In the meantime I guess I am learning a ton just trying to do basic modifications or at least what I consider, "basic" to be. Within the next few days my belts and pullys should be here and I will start printing with the dual extruder setup so ill keep you guys updated on the progress as I will be adding an lcd after I chase down the dual e issues.

Tdeagan wrote:There are a couple contributing problems, the first of which is the number of places that state something like"This version is for supporting Printrboard The copy at https://github.com/PxT/Marlin is the official source as shipped by Printrbot HQ."

That may have been true at a point in the past, but is (apparently) no longer accurate. In his videos, Brooks is promoting https://github.com/Printrbot as the official site.

The Marlin code has a gazillion forks. This is the network chart of the Printrbot site's code: https://github.com/Printrbot/Marlin/network You can see the fork by PxT a little ways down and by scrolling around you can see that PxT had commits as late as June 4 that haven't been committed to the Printrbot fork.

Both PxT and Printrbot were forked from Lincomatic which was forked from ErikZalm which is the top of the network (his network graph show the terrifying number of forks out there for the unwary.)

Can you explain how different forks would use different "pin" numbers for the very same hardware? Especially in light of the fact that supposedly the next layer up in the logical chain is Arduino sofware which is "hardware-agnostic" meaning the same logical pin number always has the same function, no matter what hardware it's running on? So we have constant Printrboard physical hardware and constant Arduino logical hardware, but our pin numbers are still changing???? I don't get it. (But then, I've never programmed in Arduino. I've programmed in assembly language on the 6502 [the heart of the Commodore 64 and the Apple II], and I've programmed in several other languages, but never in C or its variants.)

I'm with you on the confusion. I left a comment on the pins.h checkin that changed the pin numbers in the most recent printrbot firmware asking what abstraction layers are in play.

I not that lincomatic got frustrated on this topic and talked about it in his blog at http://blog.lincomatic.com/?p=537. Both of the forks we've been discussing are forks of lincomatic's code, so we may be dealing with the very issue his blog post is talking about (or not, I'm having a _very_ difficult time sussing this out.)

I'm now digging into the core_pins.h file that lincomatic talks about. It's not in the actual firmware source, it's in the arduino-????\hardware\at90usb1286\cores\at90usb1286 subdir that the teensyduino stuff sets up.

I've added the core_pins.h definitions. Clearly a lot of those are in use. One explanation for the pin numbering switching we see is the use of different def files. But I'm still not clear on which ones/when/how.

The 'key' between the different definitions is the PIN, i.e. PINA0 is what I'm matching every instance of something referring to port A, bit 0 to, wherever something refers to it.

lwalkera wrote:The USB connection disappearing is more a result of Brook just ordering the cheapest LCD he could find, not checking the specs, and ending up with 3.3V LCDs. Fortunately, the only thing different is the value of the current limiting resistor for the backlight. You can disconnect LCD backlight and stop the overheating and browning out by unsoldering the solder jumper on the back of the LCD to the right(when the front is facing you) of the pin header.

This is incredibly helpful!!

Might have been nice to hear this from Printrbot before I repeatedly tried hooking it up to my bot and flashing/reflashing firmware...

I put in a broken part request to Printrbot. Given that it was a $65 component, I'm not over-eager to just fix it (or semi-fix) myself. A backlight is pretty useful on these displays. Almost every other LCD/controller board with identical functionality/parts on the market costs less than $55 and many less than $45.

Option 1 - Wait for Printrbot to replace this with a viable 5V unit (Ouch, how long will this take?)

Option 2 - See if Printrbot will send me a 5V LCD and I'll desolder/resolder it myself (Less ideal, but possibly a lot faster)

Option 3 - Buy my own 5V LCD (or steal one from another project) and desolder/resolder it myself (Doesn't make me happy for the $65 I spent)

Option 4 - try making a patch cable that lets me use my LCD controller from my RAMPS 1.4 (Still doesn't make me happy for the $65 I spent, but could hold me until Option 1 materialized)

I understand Port A Bit 0 etc, and I can see from the schematic and from the Atmel data sheet how that maps to a physical pin on the chip. That's the kind of programming I cut my teeth on back in the day.

And I understand the concept of - and the reasons for - a level of abstraction. I have used it myself.

But you still have to have unique identifiers, don't you? It looks like you have duplicates for most of the range 0 - 9

RetireeJay wrote:I understand Port A Bit 0 etc, and I can see from the schematic and from the Atmel data sheet how that maps to a physical pin on the chip. That's the kind of programming I cut my teeth on back in the day.

And I understand the concept of - and the reasons for - a level of abstraction. I have used it myself.

But you still have to have unique identifiers, don't you? It looks like you have duplicates for most of the range 0 - 9

I don't want to BS you, I'm nowhere near understanding how these defs are getting back to the actual physical pins. My fantasy is that if I spend ridiculous hours documenting everything I can find, I'll level up and get the 'clue' achievement. (Or someone in the know will take pity and just explain it )

Quick question as lcd related things are by no means my strong part but, couldn't you buy an I2c lcd with 5v and wire it to work the same as buying a Printrbot one. I ask because I am looking for a cheap solution. I know you can buy them for less than 10 bucks and even get them with a built in sd card. Any info would be great.

The firmware is set up to expect a 4x20 LCD (driven in 4-bit mode). I haven't looked at the other marlin options, there may be an i2c option in there, but it wouldn't be happy coming off the Printrboard ext2 pins without a lot of new code. It's also looking for a rotary encoder switch for menu selection.http://www.adafruit.com/products/377 The LCD and the rotary encoder could be bought for as little as $15 combined and breadboarded to work just as well as the Printrbot LCD controller.

I used a standard RAMPS 1.4 LCD smart controller with a very simple patch cord. I see those on the market for as low as $40. They work exactly the same as the $65 Printrbot LCD controller.

I am addicted to the LCD and controller at this point, having that control makes printing a good bit easier for me.

Check out my post above. I used some breadboard jumper cables and figured out the patch and it works great! Not all the ramps controllers are exactly the same, but they're all almost identical. All of them should be pretty close but I'd check the schematic to make sure.