bitboxelectronics / r2c2_firmware Goto Github PK

Currently to update firmware, the user has to press buttons and copy the file to the SD drive etc.

It would be more convenient to have this process under program control. To help with this, we need a Gcode command to tell the printer to enter "update mode". In the Update Mode, the printer suspends normal operation and exposes the SD card via USB Mass Storage Class. The host can then copy the firmware to the SD card, and then eject the SD card.

We can use the current bootloader for this, we just need a small area of RAM reserved for the firmware to communicate with the bootloader. When the firmware receives the Enter Update Mode command, it writes into the RAM area a code to indicate update is being requested, then performs a reset.

When the bootloader starts up, it should look at the RAM area to see if it is valid. If there is a update request there, then it stays in the bootloader instead of jumping to firmware. If the firmware is not valid/not present then it will stay in bootloader anyway.

An alternative method is to include the USB MSC as well as CDC in the main firmware, as removable drive. Normally the SD will be "not present". When download is requested, the SD card is "inserted" and the host can copy firmware. The host can then eject the SD card as before, and the bootloader will see the firmware and update it.

If a command line contains a valid word such as "X100" but no other G or M code, the GCode parser should implement the current modal command, e.g. G1. I think this used to work, but may have got broken somewhere.

Generally 3d printer software does not generate such commands, but it is more common in CNC/CAM files.

From "The NIST RS274NGC Interpreter - Version 3"

3.3.7 Commands and Machine Modes
In RS274/NGC, many commands cause a machining center to change from one mode to another,
and the mode stays active until some other command changes it implicitly or explicitly. Such
commands are called “modal”. For example, if coolant is turned on, it stays on until it is explicitly
turned off. The G codes for motion are also modal. If a G1 (straight move) command is given on
one line, for example, it will be executed again on the next line if one or more axis words is
available on the line, unless an explicit command is given on that next line using the axis words or
cancelling motion.

I built firmware from last commit (36dc037) and tested to print the Android magnet(1). As seen on the video(2), it prints however there are some movements that are done very slow, at different velocity they should be done. An example are the Z movement at the end of each layer that happens to be very slow.

I am printing a lot of the Android magnets using latest stable firmware(3) and all the movements are correct. It works very well however this version misses some functionalities like the beep GCode command and others...

(1) http://www.thingiverse.com/thing:10434
(2) http://www.3dprinting-r2c2.com/?q=content/printfbot-prints-new-reprap-3d-printer
(3) https://github.com/bitboxelectronics/R2C2_Firmware/blob/master/stable_bins/R2C2_RepRap_firmware-2011.12.02.bin

This is a problem with the way the GCode standard is misused as a comms protocol. When the printer queue is full, the host won't send further commands until the one that is blocking the queue is completed.

Please see "documents/improved_printer_protocol.odt" for a discussion of the problem and a simple solution. By adding a "Busy" status to the protocol, the host can send commands even when the print queue is full. The printer will process the command if it can, otherwise it returns "Busy", and the host must retry later. In the meantime the host can send any other commands instead, such as Stop or Get Temperature etc.

When I home the machine with G28 command, the Z homing hangs. If I revert this commit "Implement accurate acceleration profiles - 4bef47f" all works ok.

I started to wrote a message to dev group with subject "Issue on firmware -- Homing Z hanging":

I found that the Z homing sequence doesn't happen in totality. Here
is the current code:

static void zero_z(void)
{
// hit endstops, no acceleration- we don't care about skipped steps
SpecialMoveZ(startpoint.z - 250, config.homing_feedrate_z);
<-------------------- This works

synch_queue();

// move forward a bit
SpecialMoveZ(startpoint.z + 1, config.search_feedrate_z);
<-------------------- This works

// move back in to endstops slowly
SpecialMoveZ(startpoint.z - 6, config.search_feedrate_z);
<-------------------- This doesn't happen!!! Machine hangs.

synch_queue();

// this is our home point
//startpoint.Z = current_position.Z = config.home_pos_z *
config.steps_per_mm_z;
tTarget new_pos = startpoint;
new_pos.z = config.home_pos_z;
plan_set_current_position (&new_pos);

// move back in to endstops slowly
SpecialMoveZ(startpoint.z - 6, config.search_feedrate_z);
<-------------------- This doesn't happen!!! Machine hangs.

I found that this works, moving Z only in positive way. Maybe the
problem is a negative value of Z axis...

// move back in to endstops slowly
//SpecialMoveZ(startpoint.z - 6, config.search_feedrate_z);
SpecialMoveZ(startpoint.z + 6, config.search_feedrate_z);

Setting the home_direction_x or home_direction_z config items to +1 still homes in -1 direction.

The code needs changing to use the config settings for X and Z.

If using a relay for the heated bed, the switching time of the HB output is too fast. Due to noise reading the temp, it causes the relay to chatter around the threshold temperature. To reduce wear on the relay, the switching time should not be more than every second.

The thermal response time of the HB is quite slow, so does not need to be switch very fast.

This is not a problem if using a MOSFET, so I suggest having a config option to select tthe rate, e.g. heated_bed_rate = 1.0 // rate in Hertz.

A hysteresis range would also help.

I am in the process of testing a new machine
After changing the information in the configuration file i performed the following operation
homed the x axis
then i ran a short gcode that moved 600mm and then returned 600mm
The x axis move past the 600mm mark and of course hit a hard endstop. and stalled the motors.
I then reset the board homed the x axis again this time i hit the reset button and then ran the gcode. this time the movements were as planned 600mm + direction and 600mm - direction
there seems to be a bit of a bug in the firmware.

I have installed the Sourcery G++ Lite 2010q1-188 for ARM EABI,eclipse 4 on window 7 ,And I have compiled the R2C2_RepRap_firmware successfully,but failed to compile the R2C2 USB bootloader.c/c++ build -> tool chain editor ->current toolchain (arm windows gcc(sourcery g++ lite)) current builder (arm sourcery windows gnu make builder), and the error is :
cs-make all
cs-make: *** No rule to make target R2C2-USB_bootloader_v2', needed byall'. Stop.

any document about how to compile the bootloader?
thanks....

A comment such as

( fill Diaphragm_Period_(layers): 100 )

is parsed incorrectly, leading to incorrect commands being executed.

In gcode_process.c , the SD card is not mounted, but relies on it being mounted earlier by config.c. This is not reliable as the variables used are no longer in scope.

gcode_process.c should mount/dismount the SD card with a file level variable as needed.

This could be viewed as a bug or feature request.

Gcode files for CNC/CAM often use multiple commands per line, eg. "G54 G90 G49 G80".

Multiple commands are allowed within certain limits in the GCode spec. There is also a defined order for executing the commands. There are more details in "The NIST RS274NGC Interpreter - Version 3". http://www.isd.mel.nist.gov/documents/kramer/RS274NGC_3.pdf

A command such as G92 X100 should set X pos to 100, but always sets to zero. Same for X,Y etc.

Only in the case of G92 with no parameters should all coordinates be set to zero.

Reference: http://reprap.org/wiki/G-code#G92:_Set_Position

The G4 command seems to hang indefinitely.

e.g. G4 P4

should wait 4 seconds and continue but hangs.

This is a work package to implement various functions typically used by CNC machines.

Also see issues #4 and #5

References to GCocde specs for CNC systems:

http://linuxcnc.org/docs/html/gcode.html
http://machmotion.com/cnc-info/g-code.html/

• feed rate should be sticky e..g line with "F2.0" sets feed rate for following commands
• G83 canned cycle peck drilling
• modal G commands such as G1, G83 should be sticky i..e a line "X10.0 Y1.0" should execute the last modal command
• G80 cancels modal command
• M6 manual tool change. this probably requires support from Control Panel
• M30 end program. when running from file, following commands should be ignored. not sure of effect if in remote mode

In some cases the SD card may not be available, or not present. Investigate ways to program the firmware without requiring an SD card.

1. Map the program Flash to a FAT disk, and use MSC. MSC is widely supported and in theory allows a user (or a programming tool). The problem is that the host OS is responsible for allocating the blocks and order of writing. So we can't guarantee that the file blocks will be written in the order and position that the firmware image requires. This method is therefore unreliable between different OS flavors or versions.

We could use raw access via dd or equivalent, but this requires a custom programming tool or script for at least Windows/Linux versions and others.

2. Have a "console" interface in the bootloader using CDC. When in the bootloader, the bootloader accepts commands via USB CDC. A simple protocol allows the host to write to blocks in flash, verify contents etc.

This requires a custom program, but the advantage is that APIs for serial interface are fairly easy to port between platforms. Additonally, the download will work over UART just as well, and could also be used over TCP/IP as a telnet type application.

Gentleman:

Can you please let us know if this company (www.3dprinting-r2c2.com) is still in business? We sent a couple of emails 3 days ago asking if PayPal can be used to purchase their R2C2 Starter Kit. We live in the US and need to purchase in USD$.

I’m interested in this board kit, please let me know if this project is still alive and being supported.

Thanks

Currently the "wait for temp" option waits for extruder temp but not heated bed temp.

We should probably also align the firmware with the Reprap gcode standard, there are various commands to set temp with wait/ no wait (M104, M109, M116 etc).

Not sure whether this is a bug or a feature request...

Some proposed enhancements for the configuration:

1. define acceleration limits per axis
2. allow specification of which pins are used
3. allow user to reverse direction of axes, sometimes easier than changing hardware
4. specify the machine type, e.g. 3d printer, XYZ milling and machine model e.g. mendel, rapman, etc
5. allow configuration of axes for other machine types, e.g. XYZA, XYAB, dual extruders

I suggest that the pin config should be in a separate file.