If you get "commands waiting" and can't connect...

[mreiben]

I have been searching for two days to try to fix this and I hope that a few people here might have an answer. I am using a printrboard on a prusa mendel build, and all of the hardware is connected and ready to go, but I can't seem to make the next easy step of connecting the printer to my computer.

I have installed pronterface on windows, osx and ubuntu, and in each environment I have been unable to connect to my printer. On windows only "com3" shows up as a port, but it wont connect at any baud rate. On the mac tty.usbmodem12341 is an option, but it also will not connect at any baud rate.

The "getting started" documentation seems to suggest that downloading pronterface and slic3r should boot right up, but I have been struggling. Any advice?

Thanks!

[pocketscience]

Assuming you've checked all the obvious stuff like 12V power to the board (green LED is on) it sounds like it might be a HW fault.


G.

[ecnelutalf]

At least for windows have you installed the necessary file: http://pjrc.com/teensy/serial_install.exe
Be sure to install as administrator.

Also, I have found that I need to boot up in the following order.
1.) Turn on power supply first
2.) Plug into computer
3.) Open Pronterface

Any deviation will leave me with the connecting message....

Hope this helps

[pocketscience]

There's nothing extra to install for Mac (that's what I'm using), so the fact he sees the same issue on all platforms suggests something more than installing the FTDI drivers for Windows - although it's a good point to confirm. On my Mac I don't have to follow any set procedure to connect to my board and overall the Printrboard/pronterface connectivity seems pretty stable.


G.

[ecnelutalf]

Try this. Disconnect and turn off power. Then unplug your Y-end stop. Then try connecting.

[scantrontb]

Try this. Disconnect and turn off power. Then unplug your Y-end stop. Then try connecting.

for the un-initiated... why unplug the stop? what does that do for you in this?

[monstermark]

I have the same issue. If my y-axis is not at 'home' then I cannot connect. It made me crazy until I finally figured out it was the end-stop causing the issue.

[jr57k]

2 points

1) the printrboard doesn't use the FTDI USB to serial chip like most other older arduino based solutions. It uses a different ATMEL chip for the main processor that doesn't rerquire this intermediate chipset but instead has a VCP built in. Based on your comment about COM3 I'm guessing you hadn't loaded the proper driver per the instructions page on printrbot.com. Once you do that another serial port should present itself, usually something higher than COM4 (mine is 14 for example). It's a much better solution with fewer errors and better stability. BTW 115200 is what you should be aiming for on the connection speed.

2) while not directly related to your problem of connecting, I have had to unplug the board and plug it back in (do this at the computer end please to avoid breaking the micro USB connector on the board itself) when I abort a print by turning the power supply off and back on again. The board when it reboots doesn't like to talk through the stale connection that was present before the power cycle. I thought I'd mention it because it's a little nagging thing that may be tripping some people up.

[pocketscience]

2) while not directly related to your problem of connecting, I have had to unplug the board and plug it back in (do this at the computer end please to avoid breaking the micro USB connector on the board itself) when I abort a print by turning the power supply off and back on again. The board when it reboots doesn't like to talk through the stale connection that was present before the power cycle. I thought I'd mention it because it's a little nagging thing that may be tripping some people up.

That sounds more like a PC thing than a Printrboard thing... I have never had any issues with my setup connecting after aborting a print, and I've done that many times...

Good info on the FTDI slip-up of mine though - I'd temporarily forgotten about the AT90 Laine used.. comment about installing the driver still stands though..


G.

[monstermark]

That sounds more like a PC thing than a Printrboard thing... I have never had any issues with my setup connecting after aborting a print, and I've done that many times...

Good info on the FTDI slip-up of mine though - I'd temporarily forgotten about the AT90 Laine used.. comment about installing the driver still stands though..


G.

Wow, you must be a customer service rep. That's a typical answer for them. Maybe next time you can say, 'try rebooting and call back later...'

Since several people HAVE had hardware issues related to connection, maybe its an intermitant board issue and not a pc, wiring, or config issue.

What revision board do you have?

[mreiben]

I have rev. c, and according to the seller it is tested with merlin firmware pre-installed. Could a firmware problem be causing this?

Thanks for the replies so far, as soon as I get home I will check the drivers that I installed, do a calculated power-reboot cycle, and try disconnecting the y-axis endstop.

[monstermark]

I have a rev b and rev c board.

Funny thing is this same thing happens on the rev c board.

Try this;

before you power on the power supply or connect the USB to your computer make sure the y-axis is at home.

Next turn on the power supply.

Then connect the usb.

Now click the connect in pronterface.

You should connect just fine.

The limit switch is n/c (normally closed) when it is not depressed, I have a belief that this is causing an issue with the board. There are others with rev c and the same issue.

I have just learned to live with it since it only bugs me when I forget to home the axis before I connect.

Good luck.

[ecnelutalf]

I have a rev C board too. I also have the problem that I cannot disconnect the USB port during an SD print or I lose power to the board.

I PM'ed Laine about it and he said it may be the version of the firmware put on it. His works fine, but the vendor may have inadvertently used a slightly larger firmware install that exceeds the space capacity of the board. Some of the code would be left out, not enough to make it not work, but will create problems.

[scantrontb]

I PM'ed Laine about it and he said it may be the version of the firmware put on it. His works fine, but the vendor may have inadvertently used a slightly larger firmware install that exceeds the space capacity of the board. Some of the code would be left out, not enough to make it not work, but will create problems.

not knowing exactly how these boards are mass produced... but shouldn't that basic kind of screw up be caught in ANY kind of QC check what-so-ever? if you don't KNOW it's loaded right, then you could be shipping faulty product right from the start, and that makes for a bad reputation, not only for PBHQ, but for the company doing the mass production/loading... also, why doesn't the firmware program loading process give any FEEDBACK as to whether or not the firmware got loaded CORRECTLY, or even at all? that just sounds stupid, as i would expect them to pay attention to the feedback for a reason, and if it DOES and they're ignoring it, then that's an even worse problem. and if trying to fix that doesn't work, can't Laine just COPY HIS firmware (that seemingly works correctly) and just post it/redistribute it to those that need it? it apparently looks like everyone with a rev. C. at least will need it, and possibly even some with a rev. B. board, too?

[lwalkera]

All of the rev C boards were made without a review from me. As far as I know, all the rev C boards (which were all made for people other than Printrbot) were all loaded with the LUFA CDC bootloader instead of the Atmel factory-programed FLIP bootloader. The LUFA bootloader is limited to only 64k of code space because of the protocol they chose.

With SD support enabled, Marlin can get close to or exceed 64k depending on the other features that are enabled and the version of gcc it was compiled with. If you have an AVR ICSP cable, I'd try reloading the stock bootloader from here http://www.atmel.com/dyn/resources/prod ... -1-0-1.zip and reflashing Marlin with the FLIP software from Atmel.

[pocketscience]

That sounds more like a PC thing than a Printrboard thing... I have never had any issues with my setup connecting after aborting a print, and I've done that many times...

Good info on the FTDI slip-up of mine though - I'd temporarily forgotten about the AT90 Laine used.. comment about installing the driver still stands though..


G.

Wow, you must be a customer service rep. That's a typical answer for them. Maybe next time you can say, 'try rebooting and call back later...'

Since several people HAVE had hardware issues related to connection, maybe its an intermitant board issue and not a pc, wiring, or config issue.

What revision board do you have?

What's your problem??!! Seriously... this is why forums get such a bad rap... people respond pleasantly with as much information as they have at hand, as I did, and then *****'s come along and criticise someone for simply giving feedback. The fact that not everyone has the same problem is actually useful information if you care to think about it for more than a nano-second.

Have a nice day,
G.

[jr57k]

As for the PC thing, it's odd because I've got like 9 computers at home, 5 macs, 4 Win7 machines. For some reason although I'm a mac guy and I program on one at work all day I've only printed from the PCs.

As for the crappy responses..... Welcome to printrbottalk.com!

[scantrontb]

All of the rev C boards were made without a review from me. As far as I know, all the rev C boards (which were all made for people other than Printrbot) were all loaded with the LUFA CDC bootloader instead of the Atmel factory-programed FLIP bootloader. The LUFA bootloader is limited to only 64k of code space because of the protocol they chose.

With SD support enabled, Marlin can get close to or exceed 64k depending on the other features that are enabled and the version of gcc it was compiled with. If you have an AVR ICSP cable, I'd try reloading the stock bootloader from here http://www.atmel.com/dyn/resources/prod ... -1-0-1.zip and reflashing Marlin with the FLIP software from Atmel.

so basically what you're saying is that all the Rev.C. electronics are NOT PBrd's but that they're 3rd party clones?

I assume the ICSP cable you're talking about goes onto the "ICSP" 6-pin connector just to the left of the SD Card connector, right? would/could you do a tutorial for us, or provide a link to one, on how to do the reflashing? and just searching for "AVR ICSP cable" on Google, brought up a few links to the cable itself, but they also have links to "programmers", would we also need to get one of those to actually DO the flashing?

[jr57k]

You can get a programmer at sparkfun.com. I think it's just a USB serial (FTDI) to TTL with the correct cable. Ive got two ina box somewhere. Just make sure you get the correct voltage (3.3V or 5V I can't remember.....)


Did you buy your board from printrbot.com?

[lwalkera]

All of the rev C boards were made without a review from me. As far as I know, all the rev C boards (which were all made for people other than Printrbot) were all loaded with the LUFA CDC bootloader instead of the Atmel factory-programed FLIP bootloader. The LUFA bootloader is limited to only 64k of code space because of the protocol they chose.

With SD support enabled, Marlin can get close to or exceed 64k depending on the other features that are enabled and the version of gcc it was compiled with. If you have an AVR ICSP cable, I'd try reloading the stock bootloader from here http://www.atmel.com/dyn/resources/prod ... -1-0-1.zip and reflashing Marlin with the FLIP software from Atmel.

so basically what you're saying is that all the Rev.C. electronics are NOT PBrd's but that they're 3rd party clones?

I assume the ICSP cable you're talking about goes onto the "ICSP" 6-pin connector just to the left of the SD Card connector, right? would/could you do a tutorial for us, or provide a link to one, on how to do the reflashing? and just searching for "AVR ICSP cable" on Google, brought up a few links to the cable itself, but they also have links to "programmers", would we also need to get one of those to actually DO the flashing?

Rev C was made by the same board manufacturer as the ones for PBHQ. They aren't knock-offs really, but they made some changes to the circuit without my review. Those small edits should really affect anything other than manufacturability, but they did erase the Atmel bootloader and load in the LUFA CDC one which has a 64k limit.

I have this one that works ok: http://www.sparkfun.com/products/9825 . It's not just a FTDI USB to serial cable, it has firmware in it that talks the ICSP protocol. If you have avrdude installed, the command on the sparkfun page should flash it to the board if you replace main.hex with the one from the zip file I linked earlier.

[bitswype]

Has anyone contacted brook to let him know of this problem so that others don't get stuck with the crippled boot loader?

[jr57k]

I have this one that works ok: http://www.sparkfun.com/products/9825 . It's not just a FTDI USB to serial cable, it has firmware in it that talks the ICSP protocol. If you have avrdude installed, the command on the sparkfun page should flash it to the board if you replace main.hex with the one from the zip file I linked earlier.

Yeah, that's the one I have.....

[lwalkera]

Has anyone contacted brook to let him know of this problem so that others don't get stuck with the crippled boot loader?

None of the boards sold by Printrbot have that bootloader, so no worries there.

[doctek]

Here is a bit from my notes on bringing up Printrboard (running for over 7 weeks now, we have 5 running).

Marlin firmware is installed as described by lincomatic here: lincomatic blog

I used FLIP from Atmel as described on the Printrboard Reprap Site to load Marlin.

Other than fixing motor directions, calibration, end stop sense, etc., the only real problem I had was that Printrboard would hang on booting if the Y-axis was homed. I believe this is due to the fact that Printrboard uses the /SS pin to read the Y end stop. If SDCard use is enabled and this pin is asserted, then the SPI port will not be readable and the initial SD read will hang - at least I think that's what's happening. So I moved the Y end stop to the pin for the E stop (which is not enabled by default). Doing this solved the problem with hanging on reset and the board works fine.

HTH

[scantrontb]

- at least I think that's what's happening. So I moved the Y end stop to the pin for the E stop (which is not enabled by default). Doing this solved the problem with hanging on reset and the board works fine.

HTH

the next question: does the Y-Stop still WORK? even though it's now on the E-Stop PINS, does it still provide the correct signal to the board/PF that when it gets activated by the screw, does it still tell the board/PF that it is "home"? or have you basically disabled the Y-Stop entirely by doing the move to the other pins, and because the E-Stop pins are deactivated by default in the firmware, the PBrd just ignores any signal it sees on those pins... OR... did you ENABLE the E-Stop pins and it now FUNCTIONS AS the Y-Stop instead?!

[doctek]

Great questions! Obviously, I should have been clearer.

When I say I moved the Y end stop to the E stop pin, I mean that I not only moved the connector (which would be the same as disabling it), but I modified the code in Pins.h to recognize the Y end stop on the pin formerly associated with the E stop. The result is that the Y end stop signal is now recognized on the pin formerly reserved for the E stop input.

For more info on the /SS pin and why it shouldn't be used as an input if you plan to use the SPI port, have a look at the Atmel data sheet for the 90USB1286. In fact, I think that any Atmel AVR that has an SPI requires that the /SS pin not be used as an input except as an SPI /SS control signal.

Hopefully this explanation makes things clearer.

[plexus]

Good blog post on the Y stop vs SD support issue: http://my3dprinterbuild.wordpress.com/2 ... ot-up-fix/

PrintrBoard SD Card & Boot-up fix

I had some trouble using the PrintrBoard’s built in SD card reader using Marlin firmware. I also had an issue with the Y-endstop, which I thought was unrelated, as the board would not boot if the Y-endstop was pressed (ie. if the bed was homed). The only help I found was from Lincomatic’s blog again but this time in a comment from “RustyPaint”, found here.

The issue is that the pin used by the Y-endstop is connected to the SS pin of the processor. So if the Y-endstop is closed it interrupts the SPI bus which the processor uses to talk to the SD card. The conflict also causes the board not to boot if the Y-endstop if pressed.

So the work around is that you disconnect the Y-endstop from the PrintrBoard and plug it in to the free Emergency endstop pins. You must then also configure the firmware to look at the E-stop pins instead of the Y-stop.

In pins.h, within the Marlin firmware, change line 918 from:

#define Y_MIN_PIN 20

to

#define Y_MIN_PIN 37

This solved the booting problem and now I can print from an SD card.

(Update: Just make sure your file name is a maximum of 8 characters long and the extension is a maximum of 3 characters. For example “Myprint1.g”)

Thanks to Nicolas Vicuña for pushing me to find a fix and help testing it.

NB: This post gets a fair bit of traffic. If this information helped you at all then please leave a comment.

[EpicFail]

I was just looking for something like this. it happened after I tried updating marlin, then coming back to the standard builld * though i did turn on Advance K*

[bpgoss1]

finished assembling and no activity from the printer. I've installed pronterface and attempted to connect Pronterface simply says connecting forever. I have tried ensuring that all axis's are set to home. Perhaps the following proterface error log file information will prove useful:

Exception in thread Thread-1:
Traceback (most recent call last):
File "threading.pyc", line 532, in __bootstrap_inner
File "threading.pyc", line 484, in run
File "printcore.pyc", line 97, in _listen
File "io.pyc", line 520, in readline
File "serial\serialwin32.pyc", line 212, in read
ValueError: Attempting to use a port that is not open

Traceback (most recent call last):
File "pronterface.py", line 1566, in connect
File "printcore.pyc", line 76, in connect
File "serial\serialwin32.pyc", line 30, in __init__
File "serial\serialutil.pyc", line 260, in __init__
File "serial\serialwin32.pyc", line 56, in open
serial.serialutil.SerialException: could not open port COM3: [Error 121] The semaphore timeout period has expired.
Exception in thread Thread-3:
Traceback (most recent call last):
File "threading.pyc", line 532, in __bootstrap_inner
File "threading.pyc", line 484, in run
File "printcore.pyc", line 97, in _listen
AttributeError: 'NoneType' object has no attribute 'readline'

Traceback (most recent call last):
File "pronterface.py", line 1566, in connect
File "printcore.pyc", line 76, in connect
File "serial\serialwin32.pyc", line 30, in __init__
File "serial\serialutil.pyc", line 260, in __init__
File "serial\serialwin32.pyc", line 56, in open
serial.serialutil.SerialException: could not open port COM3: [Error 121] The semaphore timeout period has expired.
Traceback (most recent call last):
File "pronterface.py", line 1566, in connect
File "printcore.pyc", line 76, in connect
File "serial\serialwin32.pyc", line 30, in __init__
File "serial\serialutil.pyc", line 260, in __init__
File "serial\serialwin32.pyc", line 56, in open
serial.serialutil.SerialException: could not open port COM3: [Error 121] The semaphore timeout period has expired.
Exception in thread Thread-1:
Traceback (most recent call last):
File "threading.pyc", line 532, in __bootstrap_inner
File "threading.pyc", line 484, in run
File "printcore.pyc", line 97, in _listen
File "io.pyc", line 520, in readline
File "serial\serialwin32.pyc", line 212, in read
ValueError: Attempting to use a port that is not open

Traceback (most recent call last):
File "pronterface.py", line 1566, in connect
File "printcore.pyc", line 76, in connect
File "serial\serialwin32.pyc", line 30, in __init__
File "serial\serialutil.pyc", line 260, in __init__
File "serial\serialwin32.pyc", line 56, in open
serial.serialutil.SerialException: could not open port COM3: [Error 121] The semaphore timeout period has expired.
Traceback (most recent call last):
File "pronterface.py", line 1566, in connect
File "printcore.pyc", line 76, in connect
File "serial\serialwin32.pyc", line 30, in __init__
File "serial\serialutil.pyc", line 260, in __init__
File "serial\serialwin32.pyc", line 56, in open
serial.serialutil.SerialException: could not open port COM3: [Error 121] The semaphore timeout period has expired.
Traceback (most recent call last):
File "pronterface.py", line 1566, in connect
File "printcore.pyc", line 76, in connect
File "serial\serialwin32.pyc", line 30, in __init__
File "serial\serialutil.pyc", line 260, in __init__
File "serial\serialwin32.pyc", line 56, in open
serial.serialutil.SerialException: could not open port COM3: [Error 121] The semaphore timeout period has expired.

Any help?

[RetireeJay]

I think that the discussion in this thread is oriented to people who want to modify their firmware on the Printrboard.

If you have a stock Printrboard from Printrbot, and you are not trying to re-flash the firmware, then your problem is probably much simpler.

Look at my post in this thread about installing the USB Serial Driver and see if it helps. viewtopic.php?f=18&t=3356&p=22269&hilit=did+you+install+the+usb+driver#p22268

[Richy_T]

2) while not directly related to your problem of connecting, I have had to unplug the board and plug it back in (do this at the computer end please to avoid breaking the micro USB connector on the board itself) when I abort a print by turning the power supply off and back on again. The board when it reboots doesn't like to talk through the stale connection that was present before the power cycle. I thought I'd mention it because it's a little nagging thing that may be tripping some people up.

That sounds more like a PC thing than a Printrboard thing... I have never had any issues with my setup connecting after aborting a print, and I've done that many times...

Good info on the FTDI slip-up of mine though - I'd temporarily forgotten about the AT90 Laine used.. comment about installing the driver still stands though..


G.

Note that he said he was aborting by using the power supply. I have noted the same occurrence myself when I have had to power things down. I'll be looking forward to if they ever add the emergency-stop feature to the firmware. Aborting by powering down doesn't seem like it's good for the printer.

[ggutshal]

I'm sorry I'm a bit confused here. I just purchased a Simple kit. I've assembled it and got the Windows driver installed. When I plug the printer in, a new COM port appears. When I click connect, it turns green. When I go to the manual control tab in Repetier, it says "6 Command Waiting". When I click any of the arrow buttons it just increases the number in the "Command Waiting" message. Both the X & Y axises are against the switch. Reading through this thread it sounds like I have to re-flash the board. Is that correct? Sorry if I'm being dense.

[RetireeJay]

No, you shouldn't have to re-flash the board.

On the right-hand side of the Repetier screen, there is an "OK" button (you may have to scroll down to see it). Some people find that they need to click on that button to get their connection going (although for some reason I never have to).

The other potential hang-up involves the serial communication. See this post: viewtopic.php?f=20&t=4280#p28089

[ggutshal]

I got that squared away now. I am using the latest version of repetier and there was a setting that needed changed (for the life of me I can't find the thread that clued me in).

[jwatte]

Some people find that they need to click on that button to get their connection going (although for some reason I never have to).

For what it's worth, I'm one of those people. I get "7 commands waiting" when first connecting, and I have to scroll down and hit the "OK" button in the bottom-right corner before the printrboard wakes up; then the printer is all happy and ready to go.

[k4rqz]

my assembled Printrbot Plus arrived today 12/10/2013 and I had the same problem with a Win7 machine. I had to go to "Manual Control" tab and "Debug Options" box there's an OK button. After hitting that, commands are sent, and everything is fine. I'm using Repetier-Host V0.90C

[holmes4]

I got that squared away now. I am using the latest version of repetier and there was a setting that needed changed (for the life of me I can't find the thread that clued me in).

It's "Set reset on connect" to "Disabled". I found this with a Google search at http://printrbot.dozuki.com/Answers/Vie ... etier+Host but it's probably in this forum too.

[RetireeJay]

but it's probably in this forum too.

viewtopic.php?f=20&t=4280

[BoingBoing11]

I had that problem too. i went to Printer Settings in Repetier Host, and set the opening handshake from low>high>low to disabled. Fixed the problem for me, hope that's helpful!