The Rambo is connected but..

[kometen]

Hi,
I have just build my Rambo and is about to test it.
I have power on, the motors and endstops are connected.
I have installed the usb driver as instructed.
In the Repetier, I can setup and connect to the Rambo via com10. The Repetier command window changes from greyed out to active.
However, I cannot operate the Motors. The commands piles up and is listed in the blue top as Command Waiting.
Pressing the OK button in the debug section reduces the waiting commands.

Please advice what can be the problem here. My OS is win 7 home.
The Power select jumper is set to PSU.

Is it possible that the USB driver is not working correctly?

PLS advice how to troubleshoot the problem.

Thanks in advance
Poul

[Polygonhell]

What are you seeing printed in the repetier TTY window?
I'm guessing it's something about the hotend and using M999 to reset?
in which case you're tripping the failsafe in the firmware and the hotend thermister has to be attached.

[CrazyE]

My H1.1, Rambo, Repetier setup was behaving similar to what you describe. Turned out I did not have the USB driver installed. John installed it and things started working properly. This was in person - I don't know where you can find the driver.

[jimrk]

I was seeing the same sort of thing..the baud rate needed to be changed in Repetier.

[kometen]

Thank for your help. Yes the Baud rate in the Repetier should be changed to 250000.
But also the termistors which shows the temperatures are required. They were not in the kit (!)
so I am now waiting for RS - Components to forward them to me.
The USB driver was correct however, thanks anyway.

Best regards
Poul

[Polygonhell]

The thermister should be in the hotend kit (my kit contains 2 one for the hotend and one for the heated bed), it looks like a tiny diode.

[ckc28]

I'm having the same problem with my Rostock MAX / Repetier setup. I've followed the assembly manual successfully up to the software installation/ limit switch calibration step. I installed the Printer drivers per the manual. My PC detects the printer on COM4, and I have configured the printer connection settings in Repetier to reflect COM4 connectivity, per the assembly manual. Then, I click the connect button (repetier GUI), and it turns green. The next step in the manual is to enter the manual command "M119", hit enter. My problem starts here. I don't get any messages in the log window, as in fig. 127 of the assembly manual.

Is baud rate important - does it need to be something specific?

I need help correctly configuring the com port settings and 'talking' to the printer with Repetier. Any help appreciated,

Thanks,

[mhackney]

Yes, baud rate is critical. The host (Printer Settings) rate MUST MATCH the firmware. I think a lot of us use:

Code: Select all

#define BAUDRATE 250000

and set that in the host too.

Make sure you understand about EEPROM with Repetier firmware and host - read the comments in the configuration.h file. Simple changing this in the firmware and uploading MAY NOT effect the change if you have EEPROM enabled and don't set the appropriate directive properly:

Code: Select all

/** \brief EEPROM storage mode 

Set the EEPROM_MODE to 0 if you always wan't to use the settings in this configuration file. If not,
set it to a value not stored in the first EEPROM-byte used. If you later want to overwrite your current
eeprom settings with configuration defaults, just select an other value. On the first call to epr_init()
it will detect a mismatch of the first byte and copys default values into EEPROM. If the first byte
matches, the stored values are used to overwrite the settings.

IMPORTANT: With mode <>0 some changes in configuration.h are not set any more, as they are 
           taken from the EEPROM.
*/
#define EEPROM_MODE 2

[halley]

Yes, baud rate is critical. The host (Printer Settings) rate MUST MATCH the firmware. I think a lot of us use:

Code: Select all

#define BAUDRATE 250000

and set that in the host too.

I'm surprised to see so many firmwares using such high baud rates. There's really no value to going so extreme, is there? Some weaker hosts can't even keep up with that speed. For instance, using an old Pentium laptop or the Raspberry Pi can work well as a CNC host, but they generally top out at 115200 bps. Since a CNC machine is mostly waiting for physical objects to move around 99.99% of the time, shaving off a millisecond to get the next gcode into the firmware is not even noticeable.

[aehM_Key]

I don't know with which types of CNC machines you were working with, but the paths for are 3D printer are usually cut in quite a lot of segments and therefore a lot of communication is needed.

[mhackney]

I'm writing a 3 part series on 3D printing for the CNCCookbook blog from the perspective of a CNC machinist. I'll cover this but consider:

Many of us use Mach3 through a parallel port interface to the machine controller. Firstly, Mach talks to the hardware machine controller through a parallel interface. Our 3D printer's RAMBo (or RAMPS or other Arduino based controller) is a USB serial interface. Secondly, Mach3 is generating the machine movement pulses from the gcode and it is these that are sent through the parallel interface to the machine controller. This has to be done in "real time" (although Windows is not a real time OS it does have some capabilities to prevent disruption of the data transfer - this is one of the primary reasons for lower rate connections on PC based Mach and EMC controllers). For our 3D printers, the gcode is actually interpreted in the firmware on the Arduino. GCode is transmitted from the host via USB to the RAMBo. This is not a real time connection - it can be buffered at both ends. In fact, if you are running Repetier host and adjust, say, the speed multiplier, it will not change instantaneously, the buffer full of code must be interpreted first. Try this on Mach3 - it is nearly instantaneous because of the "real time" nature of that interface/controller.

In practice, the buffer at the Arduino (RAMBo or RAMPS for instance) end has a finite sized buffer so ultra high transfer rates aren't going to make a big impact when printing. They may have an impact when transferring gcode files to an SD card on the controller (like that built into the LCD display).

Hope that clarifies things a little.

[Polygonhell]

There are multiple factors involved in the baudrate selection, but even at 250KBaud you'll see the arduino starved for data during things like hex infill or perimeters without a lot of straight lines. The symptom is the head stopping during a move, or motion becoming less than smooth.
Most people recommend printing from SDCard for the best quality, because it removes the issue.
Serial over USB was a poor choice of connection for a number of reasons, but it was cheap. Ethernet would have been a much better selection, but given most ethernet adapters for arduino's have faster processors on them than the arduino they are connected to I can see the reluctance to go there.
With the advent of cheap ARM boards often with ethernet support on chip, it might eventually change.

[BenB]

On the baud rate question - I have just completed building my Rostock Max and hooked it up to my computer (2012 mini mac running OS 10.8). Unfortunately I can't connect properly to the device at the moment (It gets as far as connection open, then says 5 commands waiting and gets no further). The baud rate is currently maxing out at 200K on my machine. Does any one know how to get a 250k baud rate on the OS X?

[cpunches]

On the baud rate question - I have just completed building my Rostock Max and hooked it up to my computer (2012 mini mac running OS 10.8). Unfortunately I can't connect properly to the device at the moment (It gets as far as connection open, then says 5 commands waiting and gets no further). The baud rate is currently maxing out at 200K on my machine. Does any one know how to get a 250k baud rate on the OS X?

I don't know about the Rambo board specifically, but whenever I have one of my Arduino boards connected to one of my Macs I need to reduce the baud rate to 115000 (or lower). Never have to do that when I'm running under Windows. I'm guessing it's something with OS X's serial drivers, or the USB hardware.

[Polygonhell]

I just select 250K in the repetier printer configuration menu on my Mac book pro, running 10.8.whatever.
Drivers are in the OS, so I would expect it to work on any Mac capable of running 10.8 the same way, is the option not in the drop down?

[cpunches]

Does it work ok for you? Like I said, I have Reptier running under Windows, but when using the Arduino IDE under OS X I've had to reduce the baud rate to 115000 to communicate with the board (UNO's). I haven't tried running Reptier under OS X as I thought there were some differences from the Windows version.

I just select 250K in the repetier printer configuration menu on my Mac book pro, running 10.8.whatever.
Drivers are in the OS, so I would expect it to work on any Mac capable of running 10.8 the same way, is the option not in the drop down?

[Polygonhell]

I don't think the arduino IDE will let you set anything over 115200, but I never use the terminal window there.
Repetier Host works fine for me on the Mac at 250K, but yes it's a different application that the PC/Linux version.