Welcome! Log In Create A New Profile

Advanced

RADDS work now stable with RepRap Firmware

Posted by angelo 
Re: RADDS work now stable with RepRap Firmware
June 05, 2016 05:57PM
Mark's always been incredibly helpful. (For folks who don't know, Mark Walker put a huge amount of work into getting MakerBot-style printers working seemlessly with Octoprint. He picked up the mostly orphaned GPX started by Henry Thomas and then extended it to work with Octoprint. A serious gift to the MakerBot-printer-style community.)
Re: RADDS work now stable with RepRap Firmware
June 07, 2016 08:52AM
I just bought a RADDS/Raps and Due Combo out of frustration about the Duet0.6 selling policy out there.

Now I see it doesn't come with Ethernet, which was my favorite gadget ( using web UI and no display )
Is there a chance to connect a RRDiscount 2004 LCD or do I have to get PanelDue or angelos 2004 LCD?

Sorry if this has been answered before, but this thread got pretty long sad smiley
-Olaf
Re: RADDS work now stable with RepRap Firmware
June 07, 2016 09:05AM
Quote
o_lampe
I just bought a RADDS/Raps and Due Combo out of frustration about the Duet0.6 selling policy out there.

Duet 0.6? The current hardware rev. is 0.8.5. Aside from more stable thermistor A/D reads, the 0.8.5 also has two controlled PWM fan outputs instead of one. There's lots of other improvements, but from a functional point of view those were the most important two to me.

Quote

Now I see it doesn't come with Ethernet, which was my favorite gadget ( using web UI and no display )
Is there a chance to connect a RRDiscount 2004 LCD or do I have to get PanelDue or angelos 2004 LCD?

If you want to use RepRapFirmware on RADDS, then only the PanelDue is supported.
Re: RADDS work now stable with RepRap Firmware
June 08, 2016 03:01AM
Here you will find Infos how to add a Paneldue to the RADDS sheld:
[doku.radds.org]


Mein Club: [hackerspace-ffm.de]
RADDS-Shield -> Commercial [max3dshop.de]
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 02:02AM
I tried to find the bossac command line that is used for flashing the Due board, but on the doku.radds page I only see links to this thread.
Do I have to flip through all the pages now?

edit:
OK I found a file named RADDS-v1.5.md that is a howto to program the due via bossac.
I wish this doc would be named "bossac_howto.doc" or something. My windows doesn't even know what to do with the ending .md eye rolling smiley

Edited 1 time(s). Last edit at 06/12/2016 03:03AM by o_lampe.
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 03:37AM
Hmm, now I programmed the Due with the latest RADDS.bin fw and tried to connect it through the programming USB port with pronterface@250000 and 115200. Nothing....
Mounted the RADDS board to the Due and inserted the newly flashed SD-card. Renamed the sys-dc42kossel folder to sys, but still no connection.

Does the RADDS need a 12V PSU to communicate via USB?
Do I see a LED when the SD-card is in use?

Edited 2 time(s). Last edit at 06/12/2016 03:40AM by o_lampe.
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 04:46AM
Another question:

How can I invert the stepper enable signals when using RAPS128 drivers and RRF_dc42_Radds firmware?
It's not mentioned in the config.g file that came with the firmware zip-file.

Funny sidenote: The M902 stepper current adjustment is still included in the config.g which could give RADDS users a false idea.

Other config lines, like IP address and subnet mask also don't make sense.
IMHO there is a bit of cleanup required.

BTW: Is it safe to power up the RAPS128 drivers without steppers connected? It's not mentioned in the doku....

Edited 1 time(s). Last edit at 06/12/2016 04:49AM by o_lampe.
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 06:51AM
If you are sure you flash your due with the proper RADDS bin and it flash OK you should be able to send/receive command IF your config.g configuration is OK and you have a proper wiring completed.

First you have to hook your native USB ( the one under the sd card) and com with it at 2500000.

You config.g need cleanup its a delta so here a sample of mine to help you start, check what I remove ( everything ethernet and current) :

; Communication and general
M111 S0                             ; Debug off
M550 Ptheimp		        	; Machine name and Netbios
M555 P2                         ; Set output to look like Marlin

G21                                 ; Work in millimetres
G90                                ; Send absolute coordinates...
M83                             ; ...but relative extruder moves

; Axis and motor configuration
M569 P0 S0						; Drive 0 goes forwards
M569 P1 S0						; Drive 1 goes forwards
M569 P2 S0						; Drive 2 goes forwards
M569 P3 S0						; Drive 3 goes forwards
M574 X2 Y2 Z2 S0					; set endstop configuration 

M665 R174.35 L345.32 B152.00 H400.34 X0 Y0 Z0
M666 X0 Y0 Z0 	; put your endstop adjustments here
M92 X160 Y160 Z160				; Set axis steps/mm
M201 X3200 Y3200 Z3200 E600		; Accelerations (mm/s^2)
M203 X20000 Y20000 Z20000 E3900		; Maximum speeds (mm/min)
M566 X1800 Y1800 Z1800 E600 ; Max instant speed changes mm/min


; Thermistors
;M305 P0 T100000 B3950 R4700 H0 L0	; set the bed thermistor
M305 P1 T100000 B3950 R4700 H0 L0	; set the first nozzle 
;M305 P2 T100000 B3950 R4700 H0 L0	; set the second nozzle 
M570 S180				; Hot end heat timer

; Tool definitions
M563 P0 D0 H1                       ; Define tool 0
G10 P0 S0 R0                        ; Set standby temperatures
;If you have a dual-nozzle build, un-comment the next 2 lines
;M563 P1 D1 H2                      ; Define tool 1
;G10 P1 S0 R0                       ; Set standby temperatures
M92 E295                      ; Set extruder steps per mm

; Z probe and compensation definition
;M558 P3 X0 Y0 Z0				
;G31 X0 Y0 Z4.80 P500		; Set the zprobe height and threshold

M556 S78 X0 Y0 Z0                   ; Axis compensation here

M208 S1 Z-0.3						; set minimum Z


T0                          ;Set Tool 0 by default

Some thing I dont use are commented with ;

The radds kinda need the 12V and supply the arduino with it, dont rush your thing, Do your complete wiring before trying to communicate like if you did not hook your thermistor and you trying to communicate it wont work cause the firmware gonna be in lock mode because of thermistor fail safe.

To invert signal to stepper its the S parameter from M569, check reprap Gcode page for every command parameter.

I always hear to always have stepper driver hook to the stepper before powering up and to not unhook it while power is on.
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 07:02AM
Quote
o_lampe
I tried to find the bossac command line that is used for flashing the Due board, but on the doku.radds page I only see links to this thread.
Do I have to flip through all the pages now?

When all else fails, you can search the web for "bossac due" (or similar).

Quote

edit:
OK I found a file named RADDS-v1.5.md that is a howto to program the due via bossac.
I wish this doc would be named "bossac_howto.doc" or something. My windows doesn't even know what to do with the ending .md eye rolling smiley

It is actually a document on how to setup the RADDS board for use with RepRapFirmware. Programming the Due with Bossac is just the first section out of eleven sections total. Some of those sections cover some of your other questions.

As to reading .md files, you can always search the internet for "file .md" and see what comes up. However, the entire point behind a .md file is that it is human-readable as-is without any document viewer or other special software.

Quote

Another question:

How can I invert the stepper enable signals when using RAPS128 drivers and RRF_dc42_Radds firmware?
It's not mentioned in the config.g file that came with the firmware zip-file.

See https://github.com/dcnewman/RepRapFirmware/blob/dev/doc/RADDS-v1.5.md#stepper-drivers

Quote

Funny sidenote: The M902 stepper current adjustment is still included in the config.g which could give RADDS users a false idea.

Other config lines, like IP address and subnet mask also don't make sense.

Both of these issues are discussed at https://github.com/dcnewman/RepRapFirmware/blob/dev/doc/RADDS-v1.5.md#sd-card-files.

Quote

IMHO there is a bit of cleanup required.

As per the RADDS-v1.5.md document, those files are for the Duet and need modification for RADDS.

Quote

BTW: Is it safe to power up the RAPS128 drivers without steppers connected? It's not mentioned in the doku....

I would assume so, but that's really a question for the board's manufacturer.
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 08:18AM
Thanks for the quick answer.

Isn't it a bit to strict to disable coms when a thermistor isn't plugged? How about allowing to connect to pc and then report an error?

I'm a guy who wants to test every single feature before I install the board in the printer ( and blow it all up in amicrosecond winking smiley )
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 08:38AM
Quote
o_lampe
Thanks for the quick answer.

Isn't it a bit to strict to disable coms when a thermistor isn't plugged? How about allowing to connect to pc and then report an error?

I'm a guy who wants to test every single feature before I install the board in the printer ( and blow it all up in amicrosecond winking smiley )

Comms isn't disabled when a thermistor isn't plugged. Sure, you get a warning message, but that's all. Here's a simple serial session over the native USB port using the Arduino console window,

RepRapFirmware for Duet Version 1.13beta1 dated 16/06/02

Executing config.g...Done!
Network disabled.
RepRapFirmware for Duet is up and running.
M105
ok T:21.7 B:21.5
Error: Temperature fault on heater 0: open circuit
M105
ok T:21.5 B:-25.1
M105
ok T:21.6 B:-25.7
M105
ok T:21.5 B:-25.7
M105
ok T:21.6 B:-26.3
M115
FIRMWARE_NAME: RepRapFirmware for Duet FIRMWARE_VERSION: 1.13beta1 ELECTRONICS: RADDS 1.5 DATE: 16/06/02
ok
M305 P0
T:100000.0 B:4066.0 R:4700.0 L:0.0 H:0.0 X:0
ok
M305 P1
T:100000.0 B:4066.0 R:4700.0 L:0.0 H:0.0 X:1
ok

I was able to type M105 commands as well as other commands and get responses. It may be that the control program you are using isn't configured adequately for talking to RepRapFirmware and doesn't handle well unsolicited messages from the firmware?

Note also that you can clear the error with an M562 command (e.g., M562 P0 to reset the fault for temp sensor 0). In the following, I reset the fault WITHOUT first correcting it,

M562 P0
ok
Error: Temperature fault on heater 0: open circuit
M105
ok T:22.0 B:-26.3

After resetting it, I get the error again since I didn't actually correct the fault.

Then, I correct the fault (attach the thermistor), reset the fault in the firmware, and all is well

M562 P0
ok
M105
ok T:21.2 B:22.1
M105
ok T:21.2 B:22.2

Edited 1 time(s). Last edit at 06/12/2016 08:42AM by dnewman.
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 09:01AM
Quote
radds_v1.5.md
...
USB
---

Use the Due's USB programming port for uploading firmware. This is the USB port
closest to the Due board's power jack. Use the Due's native USB port for
communication with the RepRapFirmware when it is running. The native USB port
is configured to communicate at 115200 Baud

Here it says 115200baud, not 250000? I get no response from the RADDS whatsoever.

Quote
doku.radds
Use the USB Programming port when connecting the DUE to a computer for software update or controlling the printer.

I got a response from the board when I try to connect it through the programming port. Some LEDs below the MOSFets flash once and then three of them blink dimly in a steady rhythm.

I'm trying to connect with pronterface. It worked well for the Duet0.6 and dc42 firmware.

I also added two fixed value resistors ( 77k) to T4&T0 to get rid of thermistor errors, but no difference.

I've used the sd card from my marlin printer. Is there anything I have to do to make it work for RADDS, beside copying the sys & www folders in the root directory?
Which format does the sd card need to have? Different from marlin/RRD LCD cardreader?

Edited 1 time(s). Last edit at 06/12/2016 09:07AM by o_lampe.
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 09:34AM
@o_lampe: I just went through this entire process myself with RADDS\Due, and fully documented the whole thing in pretty granular detail, here's the link if it could help you out:
[www.akeric.com]
There were a number of pitfalls I encountered (like, for example, having to hit the reset button on the due every time I turn it on, or I can't communicate with it).
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 09:45AM
Do you have a arduino R3 or R3-E ? The r3 have a boot up problem kinda, you need to hit reset after you power up the board.

You should use the native port to communicate with the firmware and it should be using 250000 unless there a problem with your host that require lower bault, (octoprint work 250000 here no problem)

The SD card should be fat32 I guess and you need the folder sys and gcode, and its folder sys you need a least the config.g the www folder you dont need on the radds.

The mosfet light you got look like the board is working, unless its a communication error its maybe an error in your config.g so feel free to post your config.g so we can check it out if its fine.

What version of the firmware did you flash on the board?

I see you reference to the reprapfirmware LCD sd card... are you trying to use that SD slot or the one on the board ?

Edited 1 time(s). Last edit at 06/12/2016 09:46AM by GroupB.
VDX
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 10:30AM
... I'm programming the Due with the Arduino-IDE 1.6.8 and programming and communicating over the "Programming Port" (nearest to the power-jack) - here I can see in "Tools/Port", which USB's are found.

For testing unknown communication speeds I'm switching between 115200 and 250000 Baud, my setting is mostly 250000

Inverting the Enable pins is done in "configuration.h" at/after line 358:
Quote

// For Inverting Stepper Enable Pins (Active Low) use 0, Non Inverting (Active High) use 1
// :{0:'Low',1:'High'}
#define X_ENABLE_ON 1
#define Y_ENABLE_ON 1
#define Z_ENABLE_ON 1
#define E_ENABLE_ON 1 // For all extruders


Viktor
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 11:32AM
Thanks for pointing out the reset problem.
I have a Due R3, but mine behaves opposite of what you ( AK eric ) described.
I can see both ports in windows device manager, but as soon as I hit the reset button, the native port disappears. Same when I don't reset and try to connect it with arduinoIDE.
ArduinoIDE shows the com port is selectable, but the name doesn't appear.
BTW The device manager names it "bossa programming port" while the real programming port ( close to the barrel jack ) is named "arduino due programming port"

This one doesn't disappear when I hit reset, but it also doesn't communicate with ArduinoIDE or pronterface.
I'm using IDE 1.63, maybe it's time to switch over to the newest?

Should I look for a Due R3-E, it seems to be the cheapest solution for this problem?
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 11:46AM
At first glance I couldn't find a Due r3-e offer.

Would it be possible to connect an external RC combo between Vcc and GND and pull down the reset pin while charging the capacitor?
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 12:31PM
So you saying your native port is called bossac in your windows manager ? Its should be call that only when you press the Erase button on the board, check if your erase button is stuck or something.
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 01:07PM
Quote
VDX
... I'm programming the Due with the Arduino-IDE 1.6.8 and programming and communicating over the "Programming Port" (nearest to the power-jack) - here I can see in "Tools/Port", which USB's are found.

For testing unknown communication speeds I'm switching between 115200 and 250000 Baud, my setting is mostly 250000

Inverting the Enable pins is done in "configuration.h" at/after line 358:
Quote

// For Inverting Stepper Enable Pins (Active Low) use 0, Non Inverting (Active High) use 1
// :{0:'Low',1:'High'}
#define X_ENABLE_ON 1
#define Y_ENABLE_ON 1
#define Z_ENABLE_ON 1
#define E_ENABLE_ON 1 // For all extruders

That's how you invert for Repetier. It's not how you invert for RepRapFirmware. One of the design goals of RepRapFirmware is that you do all configurations at run-time via gcode instead of at compile-time via #define.
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 01:17PM
Quote
GroupB
I see you reference to the reprapfirmware LCD sd card... are you trying to use that SD slot or the one on the board ?

Point being, you MUST disconnect the LCD / SD card interface from the RADDS board if you are going to use RepRapFirmware. The important part is to disconnect the SD card portion of the LCD/SD module.

As to the resetting on power up, there's something "off" with the RADDS 12/24V to 3.3V regulator or some other part of the electronics. On initial power up, something isn't yet stable and the SAM3X8E processor on the Due board is not always booted correctly. I believe many posts back there was a discussion of this. I know that I will occasionally see this as an issue on my RADDS boards but not often. They run on 24V. And I never see it when I'm just powering the RADDS/Due over USB and no peripherals are attached. In that case, the power regulation is done by the Due itself getting power off the 5V, 500 mA USB line. (Mind you, when running over USB there's a different situation: downloading firmware through the programming port usually confuses the SD card on the RADDS as it uses SPI and control lines for the SPI bus are used for firmware burning. So, it's expected that you need to do a full power cycle when programming via the programming port. Otherwise, the SD card's ASIC remains in a confused state and the booting firmware cannot access the config.g file on the SD card. This isn't an issue on electronics which use the native SD card support built into the SAM3X8E. However, RADDS had no choice but to use much slower SPI bus access as the Arduino Due doesn't expose the SAM3X8E's native/builtin MMC/HSMCI SD interface.)
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 01:21PM
Quote
o_lampe
I also added two fixed value resistors ( 77k) to T4&T0 to get rid of thermistor errors, but no difference.

There's been a number of folks having issues with the Asian clone Due cards, particularly with A/D inputs. Seems to be one of the areas where the clones cut too many corners.
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 02:50PM
Quote
o_lampe
Thanks for pointing out the reset problem.
I have a Due R3, but mine behaves opposite of what you ( AK eric ) described.
I can see both ports in windows device manager, but as soon as I hit the reset button, the native port disappears. Same when I don't reset and try to connect it with arduinoIDE.
ArduinoIDE shows the com port is selectable, but the name doesn't appear.
BTW The device manager names it "bossa programming port" while the real programming port ( close to the barrel jack ) is named "arduino due programming port"

This one doesn't disappear when I hit reset, but it also doesn't communicate with ArduinoIDE or pronterface.
I'm using IDE 1.63, maybe it's time to switch over to the newest?

Should I look for a Due R3-E, it seems to be the cheapest solution for this problem?

Which build of RRF are you using? If it's based on the 1.12 or later Duet source code then the VID and PID of the native port have changed, unless Dan reverted the relevant change. If that is the case, then you can gain access to the port by installing the Windows device driver in my github RRF repo (and Dan may have copied it to his repo too).

Edited 1 time(s). Last edit at 06/12/2016 02:51PM by dc42.

Delta printer calibration calculator, mini IR Z probe, and colour touch screen control panel: [escher3d.com]

Large delta printer, and other 3D printer blog postings: [miscsolutions.wordpress.com]

Full disclosure: I have a financial interest in sales of the Panel Due, Mini IR height sensor, and Duet WiFi.
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 03:32PM
For RADDS CoreNG is compiled

-DUSB_DEVICE_VENDOR_ID=0x2341 \
-DUSB_DEVICE_PRODUCT_ID=0x003e \
"-DUSB_DEVICE_PRODUCT_NAME=\"Arduino Due\"" \
"-DUSB_DEVICE_MANUFACTURE_NAME=\"Arduino S.r.l.\""

and those should be picked up by conf_usb.h,

https://github.com/dcnewman/CoreNG/blob/master/asf/conf_usb.h#L19.

And those values should match what the Arduino App normally bestows on the Native USB port,

https://github.com/arduino/Arduino/blob/master/hardware/arduino/sam/boards.txt#L26

Now, in keeping with the CoreNG changes, it's no longer a hybrid HID (mouse+kbd) & CTC device as with the Arduino libraries and is only a CTC device now. However, my Arduino 1.5.8beta app on OS X 10.9.5 connects fine. And others have connected fine using Octoprint (presumably on a Linux-based kernel).
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 03:47PM
Quote
dnewman
For RADDS CoreNG is compiled

-DUSB_DEVICE_VENDOR_ID=0x2341 \
-DUSB_DEVICE_PRODUCT_ID=0x003e \
"-DUSB_DEVICE_PRODUCT_NAME=\"Arduino Due\"" \
"-DUSB_DEVICE_MANUFACTURE_NAME=\"Arduino S.r.l.\""

and those should be picked up by conf_usb.h,

https://github.com/dcnewman/CoreNG/blob/master/asf/conf_usb.h#L19.

And those values should match what the Arduino App normally bestows on the Native USB port,

https://github.com/arduino/Arduino/blob/master/hardware/arduino/sam/boards.txt#L26

Now, in keeping with the CoreNG changes, it's no longer a hybrid HID (mouse+kbd) & CTC device as with the Arduino libraries and is only a CTC device now. However, my Arduino 1.5.8beta app on OS X 10.9.5 connects fine. And others have connected fine using Octoprint (presumably on a Linux-based kernel).

It may be OK for Linux, however Windows objects to the device .inf file saying it's a composite device and then finding that it isn't. Windows 10 then installs its own generic serial USB driver instead, which works fine (it shows up in Device Manager as "USB Serial Device"). However, I am told that Windows 8 and earlier refuse to recognise the device.

So if you are going to keep the Arduino Due VID/PID (which I agree is the right thing to do for Due/RADDS), then for compatibility I think you need to make it appear as a composite device.


Delta printer calibration calculator, mini IR Z probe, and colour touch screen control panel: [escher3d.com]

Large delta printer, and other 3D printer blog postings: [miscsolutions.wordpress.com]

Full disclosure: I have a financial interest in sales of the Panel Due, Mini IR height sensor, and Duet WiFi.
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 04:12PM
Quote
dc42
So if you are going to keep the Arduino Due VID/PID (which I agree is the right thing to do for Due/RADDS), then for compatibility I think you need to make it appear as a composite device.

Fortunately, I previously worked out how to do that with CoreNG and it's even in the github commit history. So, I can try it again and let people who use Windows test it.

Any interest in having the dc42/CoreNG/asf/conf_usb.h pull in an alternate conf_usb_radds.h header file or shall I keep that isolated to dcnewman/CoreNG? I don't care much either way, but figure I should ask.
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 04:44PM
Quote
dnewman
Quote
dc42
So if you are going to keep the Arduino Due VID/PID (which I agree is the right thing to do for Due/RADDS), then for compatibility I think you need to make it appear as a composite device.

Fortunately, I previously worked out how to do that with CoreNG and it's even in the github commit history. So, I can try it again and let people who use Windows test it.

Any interest in having the dc42/CoreNG/asf/conf_usb.h pull in an alternate conf_usb_radds.h header file or shall I keep that isolated to dcnewman/CoreNG? I don't care much either way, but figure I should ask.

However, what I had before no longer works correctly. (I had had a conf_usb.h file built by the latest Atmel Studio with up-to-date ASF; however, it's not producing a working USB device with recent changes to CoreNG.) So, I don't anticipate addressing this anytime soon.
Re: RADDS work now stable with RepRap Firmware
June 12, 2016 06:16PM
Okay, I've changed CoreNG for RADDS to build as a USB CDC but with the device identifying as a Duet and uploaded a new .bin file,

https://github.com/dcnewman/RepRapFirmware/blob/dev/Release/RepRapFirmware-1.13beta1-dc42-radds-a.bin

Screen Shot 2016-06-12 at 5.54.00 PM by dnewman2010, on Flickr

Screen Shot 2016-06-12 at 6.02.04 PM by dnewman2010, on Flickr

The device driver files in

https://github.com/dcnewman/RepRapFirmware/tree/dev/Driver

can be used on Windows to declare the device. (Mind you, they wouldn't install for me on Windows with a right-click install. But then, I already had the Atmel Studio driver for it installed already so it didn't matter.)
Re: RADDS work now stable with RepRap Firmware
June 14, 2016 12:37PM
It seems my Due has a stuck erase button, so I can test the new .bin file when I get a replacement board.
Re: RADDS work now stable with RepRap Firmware
June 14, 2016 02:14PM
Quote
o_lampe
It seems my Due has a stuck erase button, so I can test the new .bin file when I get a replacement board.

Can you remove it and either replace it or just short it briefly when you need to upload? Of course, if you upload via the programming port you should not need the erase button at all. I always upload via the programming port and never need to press either the ERASE or RESET button. Instead, I have a short Python script which briefly connects over the programming port and does the right trick to enter programming mode -- connect at 1200 baud and toggle DTR on and then off. I then have bossac do the programming.

  def tickle(target, source, env):
    import serial
    import time

    port = env['PORT']
    print 'Tickling the bootloader via port ' + port
    try:
      with serial.Serial(port, baudrate=1200) as sd:
        sd.setDTR(1)
        time.sleep(0.5)
        sd.setDTR(0)
    except serial.SerialException, e:
      return str(e)
Re: RADDS work now stable with RepRap Firmware
June 14, 2016 08:18PM
Is it possible to pause a print in the gcode (not via an interactive M25), then after unloading\reloading filament, start the print up again, but not via the LCD?

I need to stop my print at an exact layer height, swap filament, and restart. I saw you can introduce a M226 to pause in Gcode... but how do you then unpause it without an LCD, over the serial port? (Maybe you don't?)
I use M600 in Repetier to do this, but that then allows me to restart the print via the LCD (which I no longer have hooked up due to RRF).

Thoughts?

thanks!

Edited 1 time(s). Last edit at 06/14/2016 08:32PM by AK_Eric.
Sorry, only registered users may post in this forum.

Click here to login