RADDS work now stable with RepRap Firmware

Endstops:
In the doc states:
"On the RADDS board, the minimum endstop headers are used for the endstops: X min, Y min, and Z min. Wire your endstops to those headers"
Which is what I've done, same as with Repetier, see the attached pic. To me that looks right: All three endstop connections are on the min plugs. From L ->R on the image, I have sig to sig, - to -, and no + (as mentioned above).
Please let me know if I'm missing something here.


Fans:
With the hotend cooling fan & PLA cooling fan, I just about lost my mind. Each time I reboot it seemed to change behavior even if I didn't change code.
I've typed this post four times now, as I've rebooted and it's changed behavior each time.
Brute forcing it this way seems to make everything happy now, consistently.

M106 P0 T60 H1  ;  P0 is thermostatic.
M106 P1 H-1     ;  Must do H-1, or P1 will turn on with P0 at 60c
M106 P1 S0      ;  Must do, or P1 turns on full blast at boot.

So now the hotend cooler kicks on at 60c, and PLA cooler correctly accepts PWM from S3D or M106.
They're working now, I'll take the win!

Edited 4 time(s). Last edit at 05/30/2016 01:05AM by AK_Eric.

It looks like you are using the correct endstop locations. However, I have no way of knowing if things are wired reasonably. On my RADDS boards, I use signal, gnd, and +3v3 for each endstop. (Signal is closest to the nearby board edge, then gnd, then +3v3). Mine are active LOW and work fine. I'm running 1.09r. (I don't believe that later releases should make a difference; however, I've not had time to actually try later releases on a fully wired up board. A few other folks have though and things worked for them.)

It's the same wiring that works with Repetier on the same board. Maybe RRF requires the 3.3v lead? Since I was told these endstops used v5 for their LEDs, I should not plug the v5 into the 3.3v else bad things, so I just snipped those wires... made Repetier happy at least.
What do you think if I swapped sig and positive (just spun the plug 180)? Magic smoke, or.... ?

I suppose I'll need to invest into some new 3.3v endstops otherwise.

BTW, can you let me know what endstops you use if you know it off hand?

Edited 1 time(s). Last edit at 05/30/2016 01:16AM by AK_Eric.

I also have no problem with my endstop they are wire as Pos and Sig

and are like that in config.g :

M574 X2 Y2 Z2 S0					; set endstop configuration

Meaning all of them are High end and are wire active LOW

I note that on a prev post you use two M574 ?
a M574 X1 Y1 Z2
and a M574 X2 Y2 Z2

you dont have both of them in the same time in the same file right ?

Your if you have only one set of endstop at the High end should be

M574 X2 Y2 Z2 S1

Also note that the best way to make sure they are working is to press the switch and use a M119 to get endstop status report, far more safer that trying to move the axe see if its stop and tell me if im wrong but when you manually JOG the endstop are not active by default on RRF I think.

For your endstop if its Those ( they are many version of them with different pinout so watch that) First the radds already have a filter cap connected to the Ground and SIG so that filter cap on the swtich side you dont really need it but I dont think there any problem to have 2 filter cap.

Then there a pull up on the VCC side of the switch , the radds do not have a pull up on the shematic ( maybe software pull up ?) I dont see no harm in connecting the 3.3v to the VCC of the switch, there nothing there that really require 5V, the led will only be dimmer. In fact that probably your problem there your SIG dont see any HIGH or LOW because its floating, connecting that pull up will make the SIG be HIGH and pressing the switch will make it LOW.

DC42 can probably help you there he is electronic guy , wait for his confirmation before hook it up, but im pretty sure you need your pull up the way this switch is made.

Must ppl use a regular plain old switch, wire to SIG and VCC, no need to have a pull up or anything else.

Also must 5v sensor can be hook to 3.3v some will work some wont it depend of the sensor, the other way around is the dangerous one , Hook 5V to a 3V sensor will destroy it.

In your case DO NOT HOOK A 5V to the VCC of your switch or you will destroy your arduino PIN thats will make the endstop pin "sig" receive 5V and do not swap the vcc for the sig,

You can also tell us what mode of printer you have and post your full config.g it will help to spot error or give advice

Edited 1 time(s). Last edit at 05/30/2016 08:35AM by GroupB.

Quote
AK_Eric
It's the same wiring that works with Repetier on the same board. Maybe RRF requires the 3.3v lead?

No, RRF does not require the 3.3v lead.

Quote

Since I was told these endstops used v5 for their LEDs, I should not plug the v5 into the 3.3v else bad things, so I just snipped those wires... made Repetier happy at least.
What do you think if I swapped sig and positive (just spun the plug 180)? Magic smoke, or.... ?

I don't offhand know what endstops you have or had. However, what you were told may well be wrong. LEDs are current driven devices and will run off of either 3.3 or 5v provided that they are presented with a voltage that meets or exceeds their forward voltage. For the LEDs typically used here, that's 1.5V. Indeed, I use the old 2010 RepRap "mechanical endstop v1.2" style endstops and they work just fine with either 3.3 or 5v. All that happens with 3.3v is that the LED is a tad dimmer since there's a tad less current. That style of endstop is what MakerBot still uses to this day; it is the style commonly sold on eBay and elsewhere as an "endstop pcb".

As to the firmware, each endstop pin has the internal pullup resistor asserted. A very common wiring is to use the COMMON and NORMALLY CLOSED (NC) pins on a switch and wire them to the board's SIGNAL and GND. Then configure the endstop to be active HIGH. E.g.,

M574 X2 Y2 Z2 S1                ; set endstop configuration (all endstops at high end, active high)

(The above is from my Delta.) When the switch is not activated, GND is presented at the board's SIGNAL pin. Since the switch is configured active HIGH, the firmware sees the LOW (GND) signal (switch is wired NC) and thus the switch is seen as inactive by the firmware. When the switch is activated, it goes open as seen between the switch's COMMON and NC pins. The wire to the board's SIGNAL pin is thus not presenting anything and the microprocessor's internal pullup resistor then causes HIGH to be seen at the SIGNAL pin. Thus the firmware now registers the endstop as enabled (HIGH).

Thanks guys: First off I almost have the endstops working: Y&Z are. X is not. more below.

Sorry about the confusion in my above posts about my M547 usage: When I was listing multiple config.g M574 lines as examples of what I'd done, I didn't mean I was running multiple lines in the same file, I was just providing all test cases I'd tried.
Ok, this is now working for me: (except X)

M574 X1 Y1 Z1 S0

And thanks GroupB : the M119, that's what helped me out. As it turns out, I've been doing all my testing on the X-endstop (easiest one for me to reach from the laptop). And... the board isn't recognizing it. I presumed because of that Y&Z weren't working either. They are working just fine as it turn out.

Here's what's crazy: If I hook my ohm meter to the terminus of the endstop wires (that plug into the RADDS), I can clearly see the signal close\open as I press\release it: So the endstop is functional at the connection point to the RADDS. And if I short out the sig/ground for minX on the RADDS, M119 reports it being closed. But if I plug the switch into minX & press it, M119 reports it still open. So there's something hardware related I'll have to troubleshot at this point. Somehow the RADDS headers aren't connecting with the endstop plug wires.

On a side-note, these are my endstops "Ramps 1.4 / Makerbot 1.2" (mine are red):


Edited 1 time(s). Last edit at 05/30/2016 03:09PM by AK_Eric.

I've got the X-endstop working now too. For some reason just takes a lot of finagling to get it seated correctly. Hopefully next up I'll get some prints made.

Again, thanks to this community for all the help!

Preparing my 'start gocde' script in S3D : I've been going line-by line to make sure everything works as I expect. The snag I hit is, whenever I enter a M190 or M109, I loose USB connection, and can't reconnect at that point.
My below codes are based on the example here: [reprap.org]
Each chunk I enter line by line and watch the results.

T0
M140 S60 ;  Bed starts heating up, no wait.  M105 shows the bed heat increase.
M190 S60 ;  Set temp and wait:  Loose USB connection, cannot reconnect.  No more M105 responses.

And

T0
M104 S200 ;  hotend starts heating up, no wait.  M105 shows the hotend heat increase.
M109 S200 ; Set temp and wait: Loose USB connection, cannot reconnect.  No more M105 responses

In both instances however, the M190 & M109 are actually doing what they should: When I reset & reconnect to the printer, I can see that the heat had continued to increase.

Here's my 'tool 0' description from config.g if that matters.

M563 P0 D0 H1

Note the hotend heats and extrudes fine, with the cooling fan auto-kicking on now being a thermostatic heater.

If I do a M190 or M109 to start (no previous M150 or M104) it's the same result, loose USB.

FYI, this is the binary I'm on : RepRapFirmware-1.10+4-dc42-radds.bin

Any thoughts? Thanks!

Edited 2 time(s). Last edit at 05/30/2016 05:11PM by AK_Eric.

Maybe you need tell the firmware again its T0 before M109, Just a guess, I dont use those command, I manually set my temps and when reach I press play, this way I can also remove the plastic leak from the hotend a couple second before it print.

T0
M104 S200
T0
M109 S200

I read somewhere that sending a M109 without a Tool selection before end up in crash for previous version of firmware ( just a quick google reveal that)

Other than that , post your complete config.g so dan and dc can review it and see if there something else causing this behaviour

You might want to fall back to a known-good release for RADDS. E.g., one of the 1.09 releases. I myself have not had a chance to test any of the 1.10 or later releases. You may be seeing a re-emergence of an older bug (RADDS only) whereby an error message is sent to non-existent interfaces (e.g., a tertiary serial line, HTTP) and causes the firmware to get upset.

Same for me Im still on 1.09r I think, Its working stable no need to change whats not broken and I know dan put more time than usual on 1.09 and discover more bug that he fix in that version ( Im the guy to blame for that but HEY! the 1.09 is stable now! ) + I have a special firmware for dvr8825 and it was made only on 1.09r so im kind of stuck there waiting on makerfarm to restock the raps128 ( been waiting for that since mid of april, angelo told me he was supose to restock everyone a while ago but im still waiting, Im thinking about ordering them from euro pretty soon if they not coming to NA soon)

Can you use Panucatt's equivalent? http://www.panucatt.com/product_p/sd6128.htm. The nice thing about it is that Roy put logic onto the board to handle the inverted enable.

I re-flashed using RepRapFirmware-1.09r-dc42-radds-b.bin
Doing this:

T0 
M109 S200

Still makes me loose USB
I also see these other files available for the 1.09 release:
RepRapFirmware-1.09r-dc42-radds-a.bin
RepRapFirmware-1.09x-dc42-radds.bin
RepRapFirmware-1.09x-dc42-radds-a.bin
Should I be using one of them instead? How do I know which one I want?

I've attached my config.g as well for you dissection.
config.g

On the 'progress' side, I was able to print a calibration cube. However, it's not been as easy as I'm used to:
* Since M109 isn't working, I have to pre-heat everything, which I'm not used to (not the end of the world).
* When I print over USB via Simplify3D, it executes S3D's 'starting script' (getting everything auto-homed before print, normally would warm up the hotend/bed, etc), and then just hangs.
* Octoprint doesn't detect anything on the SD card, either in the root, or in the /gcodes subfolder.
* I can upload gcode to the OctoPi itself and print that way, but I hate printing over USB for anything other than a test.
* I just ended up printing off the SD via M23 & M24 successfully.

On the sad side, the whole point of this 'update to RRF' was to see if these weird vertical lines that have been showing up in my prints since I swiched to RADDS\Repeter went away (I figured it was maybe a Repetier/coreXY issue). They're still there... Which now makes me think this is maybe a SD6128 1/32 microstepping issue, since the stepper motors themselves haven't changed during all this config. If you're into such things, you can see some closeup pics here:
http://forum.repetier.com/discussion/1768/odd-vertical-lines-showing-up

Thanks all

1.09r xx was superceded by 1.09r-xx-a which was then superceded by 1.09r-xx-b. So you should use 1.09r-xx-b if you want to use 1.09r.

P.S. I use octoprint all the time with RRF + RADDS. Never had an issue. And my SD card files show up fine when I connect from Octoprint. Uploading to the SD card works as well. You are using the microSD slot on the RADDS board, correct? You MUST disconnect the LCD/LCD module as that WILL interfere with SD card operation with RRF.

Also, printing over USB from octoprint also works fine. You must use the Due's native USB port and not the programming port. I've never had the USB connect drop either. I just tried this with 1.09r-dc42-radds-b.bin and that's what I've been printing successfully with on my CoreXY printer. Both from SD and over USB from Octoprint on a RPi 2. (Well, now it's an RPi 3.)

So what I installed above then is correct then: RepRapFirmware-1.09r-dc42-radds-b.bin
It just doesn't solve my USB problem.

I've been using Octoprint for some time now successfully as well, but there have been a couple times where the USB connection has been the direct culprit of a failed print for me: Just wiggling the USB line made it fail, for example, two prints in a row. This raises all sorts of other questions about the hardware, but I had my old Rep1 fail over USB once as well, so I just always print off SD. No problems since.

I do connect only to the native port, not programming port.
I am saving my gcode on the microSD in the radds in both the root folder and in the /gcodes folder just to cover all my bases.
No amount of Octoprint 'initializing the sd' or 'refreshing' the SD contents will make the files show up as printable. But I can show/print all the stuff uploaded to the OctoPi SD.
I do not have the old LCD \ SD attached.

I noticed that when Octoprint does the "Initialize SD", it sends a M21 : Which isn't supported by RRF? And pressing the 'refresh' button issues no M codes at all in the serial monitor. In my octoprint settings I have 'enable SD' checked. If I uncheck it, the 'initialize SD' doesn't do anything. I also have the RepRap Pro plugin installed:
[github.com]
Since I was reading that was required.

Edited 1 time(s). Last edit at 05/30/2016 10:49PM by AK_Eric.

Correct, many of the SD commands used by Octoprint are Marlin-centric and may or may not be supported by other firmwares. When in doubt, see

http://reprap.org/wiki/G-code

Even though it's not really working for me 100% (yet), I still wanted to put together an install guide for all the steps\troubleshooting I've gone through:
http://www.akeric.com/blog/?p=3909
Sort of the 'noobs guide for installing RRF on RADDS'.
Big thanks again to all the help from everyone, especially you Dan

Thank for the link Dan but they are out of stock, just like all raps128 and eric look like he having line on his print and he think its the driver... the same you link. I know angelo told me he working on a new driver for this summer , since all THB6128 are out of stock everywhere I may as well wait for the new one, except is they really late to release. Its crazy I think reprap.me had 150+ stock of them middle of last week and now they out too.

Erick :

I just try to do a M109 after I set the hotend in octoprint and it hang so I think its a normal behaviour, You will have to ask ppl with a duet firmware 1.09 to try it see if its work, if it hang too its related to DC42 fork ( I read they already had a m109 problem on a prev version , maybe its back). Also you also missing a B argument in your first M305.

Also you said you had usb connection problem with other firmware too sometime, Try another USB cable , the shorter the better

My octoprint dont put gcode in the /gcode when you use octoprint to upload to SD ( or stream them to SD for a very long time, Its annoying) they put it directly into the SDcard directory and they change the .gcode to .gco. So my guess to see them in octoprint if you manually put them on the sd they must be .gco and in the main directory.

Also I do not have any m106 on my config for the hotend fan and its working , I think the temp is 30C but its thermo by default on the firmware for P0 ( M106 P0 T30 H1:2:3) ( I had one when I set my first config.g but I look at my lastest one and its not there anymore, I wonder why I remove it, maybe it was causing a bug...I dont remember) and P1 is my pla cooling fan control with the Gcode and its working and are not in my config.g, Your radds cooling fan you can hook it directly to the psu so its "on" when you turn the machine "on". IF your P1 go full blast when you turn your machine "on" maybe you need to invert it with the I argument, maybe that also why you said it go full blast when your put power on the board.

For your artefact problem on your print I have no idea except try to lower your accel see if this help or check if your belts are tight enough, If you want to try your 8825 to see if its driver related PM me your Email Ill send you the 1.09r made for 8825 , my 8825 are giving me circular patern if not set fast decay and even there I can see them but they very light but its a delta related thing, because of the way one axis is moving very slowly and not a lot while doing a line facing an axis.I have no idea if core XY is having the same problem I know catesian dont. Its the "Low current zone" problem where the current skip 0 to 0.6.

Thanks GroupB :
* M109 loosing USB : Interesting it has the same behavior with you. Sounds like a straight up bug at this point? I'm in contact with one person that as a Duet, they say they use M109 just fine via the duet web interface, but said they'd try it over USB for me.
* Missing B from M305 : That first line is for my bed. I have no idea what Beta value to put in there. Any suggestions or a generic100k thermistor?
* Octoprint & SD : I can't upload to my RADDS SD via Ocotprint because, like mentioned before, it's completely unrecognized, that button is grayed out. Octoprint has no knowledge of the SD on the RADDS, I have no idea why. But from Octoprint I can print from the RADDS SD, by calling to the M commands (listed above) directly.
* Hotend & PLA cooling fans: I'll look more into it based on your suggestions.
* Case cooling fan: That's exactly what I did, hooked it directly to my powersupply. Seems clunky though, Repetier let me power it by any arbitrary pin, and it would only kick on if the steppers were active. Nice touch I'm now missing.
* Print artifacts: I've confirmed it's independent from both acceleration & belts: I can lower accel & jerk & print slower, they still show up. I've loosened & tightened my belts and they still show up the exact same. Next up I'll switch to 1/16 microstepping and see what impact, if any, that has.

Edited 1 time(s). Last edit at 05/31/2016 05:44PM by AK_Eric.

Quote
AK_Eric
Thanks GroupB :
* M109 loosing USB : Interesting it has the same behavior with you. Sounds like a straight up bug at this point?

Actually, I believe it is working correctly. Howver your expectation doesn't align with RRF and thus "correctly" may not appear so to you. First, know that M109 is considered deprecated in RRF and shouldn't be used. Second, the implementation in RRF does exactly as the command suggests: stop processing further commands until the set temperature is reached. As such, the firmware stops processing new commands from that command stream while it waits for the temp to be reached. I sent

M109 S50

from Octoprint and the bot received it and stopped responding to new commands from Octoprint until 50C was reached. Once it was reached, it resumed processing commands from Octoprint, And, note that commands were accepted from other command streams: my PanelDue which uses and aux. serial line was having its status checks accepted and processed while Octoprint was left waiting. I'm confident that if I printed from SD card then Octoprint would have seen its queries accepted and processed as well. But since you were printing over USB, the queries sent over USB were held at arms length until the commanded temp was reached -- the printer was, after all, told to stop processing further commands until the temp was reached. That is what M109 means after all.

Recv: ok T:24.2 B:24.4
Send: M109 S50
Recv: ok
... PAUSE FOR ABOUT 20 seconds until the extruder reached 50C ...
Send: M105
Recv: ok T:49.0 B:24.4
Send: M105
Recv: ok T:49.4 B:24.4
Send: M105
Recv: ok T:48.7 B:24.4

Quote

* Octoprint & SD : I can't upload to my RADDS SD via Ocotprint because, like mentioned before, it's completely unrecognized, that button is grayed out. Octoprint has no knowledge of the SD on the RADDS, I have no idea why. But from Octoprint I can print from the RADDS SD, by calling to the M commands (listed above) directly.

You may have Octoprint still configured and thinking it is talking to Repetier? (Under Settings > Features there's some Repetier only settings which you need to uncheck.) With Repetier I believe the SD card does need to have a command sent to initialize the SD card system. And that command isn't used by some of the other firmwares and, in the case of RRF, fails. That may be leading Octoprint to behave that way. I have my Octoprint configured for a generic RepRap printer. And when it connects it sends a M20 command and learns of all the card files. It also allows upload of files to the SD card,

Connecting to: /dev/ttyACM0
Changing monitoring state from 'Offline' to 'Opening serial port'
Connected to: Serial(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Changing monitoring state from 'Opening serial port' to 'Connecting'
Send: N0 M110 N0*125
Connection closed, closing down monitor
Recv: ok
Changing monitoring state from 'Connecting' to 'Operational'
Send: N0 M110 N0*125
Recv: ok
Send: M105
Recv: ok T:24.5 B:24.7
Send: M21
Recv: ok
Send: M20
Recv: Begin file list
Recv: coathook.g
Recv: duettest.g
Recv: ormaxis.g
Recv: snowman.g
Recv: square.g
Recv: whistle.g
Recv: Cthulhu.g
Recv: a.gco
Recv: a2.gco
Recv: a3.gco
Recv: End file list
Recv: ok
Send: M105
Recv: ok T:24.4 B:24.9

Thanks Dan:
You raise a good point about the M109: I'm used to after that being sent (by say, S3D over USB to Repetier) the M105 keeps printing temps correctly. With RRF it stops the M105 prints: I figured this meant I lost USB, but in fact maybe it's 'just paused' like you suggested: I never actually let it keep running until full temp: I'll be sure to test this soon. Hopefully you're right!

For Octorpint & SD: I'm familiar with the checboxes you're referring too: They're all checked off.
Again, I can interact with the SD card via Octoprint via Mcodes through the serial monitor : List them, print them. But Octoprints UI says I have no SD card to either print from, or upload too. Frustrating

Quote
AK_Eric
For Octorpint & SD: I'm familiar with the checboxes you're referring too: They're all checked off.
Again, I can interact with the SD card via Octoprint via Mcodes through the serial monitor : List them, print them. But Octoprints UI says I have no SD card to either print from, or upload too. Frustrating

I suspect it's some sort of Octoprint config issue as we're both running the same RRF for RADDS build and this works just fine from my Octoprint v1.2.11. (And it's worked with prior OP versions as well.)

Note that I have "always assume SD card is present" CHECKED. (Also the enable SD support check box.)

Octoprint not seeing the SD card: Got it working, based on your suggested "Always assume SD card is present [REPETIER]" : I had unchecked that, thinking it was a Repetier only option. Finally, Octoprint is fully functional, huge thanks.

M109: You are right: When I run that is blocks all communication until it hits target temp, but after target temp is reached communication resumes. It's still sketchy though, since you can't communicate with the bot at all during that time (no emergency shutdown), thus you can't stop if from heating if needed. That is different behavior than what I've experienced with Sailfish\Marlin\Repetier... don't really like how it's implemented, seems unsafe. I can work around it by just not using it, but it's awfully handy to just say "go", and the machine doesn't do anything until it's reached the appropriate temp, automatically.

Huge thanks again for all your troubleshooting help. Now I can finally actually start tuning it

Quote
AK_Eric
M109: You are right: When I run that is blocks all communication until it hits target temp, but after target temp is reached communication resumes. It's still sketchy though, since you can't communicate with the bot at all during that time (no emergency shutdown), thus you can't stop if from heating if needed. That is different behavior than what I've experienced with Sailfish\Marlin\Repetier... don't really like how it's implemented, seems unsafe.

Again, M109 is considered deprecated for RRF. Use M116. It's also, btw, supported by Repetier and more versatile (supports chamber heaters).

An issue you may be having is assuming that Repetier gcode works for RepRapFirmware. Whenever I try to use a new firmware, I check each and every G and M code. There's just too many exceptions between different firmwares. I also find it useful to look examples meant for a given firmware. See, e.g., https://github.com/dc42/RepRapFirmware/tree/dev/SD-image/gcodes-Ormerod.

@GroupB

Since Yesterday wie have all RADDS / Raps128 / RADDS-Display / Hall-E / RADDS-Extension-Board etc ..in Stock again.

For the USA reprapers .. I have send some RADDS+Raps128 ... To Makerfarm.
[www.makerfarm.com]

Sorry for that.
Angelo

---

Mein Club: [hackerspace-ffm.de]
RADDS-Shield -> Commercial [max3dshop.org]

Quote
dnewman
Again, M109 is considered deprecated for RRF. Use M116. It's also, btw, supported by Repetier and more versatile (supports chamber heaters).

An issue you may be having is assuming that Repetier gcode works for RepRapFirmware. Whenever I try to use a new firmware, I check each and every G and M code. There's just too many exceptions between different firmwares. I also find it useful to look examples meant for a given firmware. See, e.g., https://github.com/dc42/RepRapFirmware/tree/dev/SD-image/gcodes-Ormerod.

Hear you on the M109 deprecation: Other than you telling me, how would I know this? I've been going off of this page's links: [reprap.org] And they don't mention the deprecation. That being said I've seen plenty of out dated stuff on that (reprap.org) page. But I'm always looking for a better source.
I gave M116 a shot: It still seems to lock up all communication while it's enabled though.

I use Simplify3D for all my slicing & gcode output, and it's worked fine (so far) outputting to Sailfish, Marlin, and Repetier: I get what you're saying with trying new firmware, and how they can differ in gcode behavior. I know just enough to make myself a danger... to myself. Introspecting those gcodes is a darn fine idea: Thanks for that link.

Quote
AK_Eric
Hear you on the M109 deprecation: Other than you telling me, how would I know this? I've been going off of this page's links: [reprap.org] And they don't mention the deprecation. That being said I've seen plenty of out dated stuff on that (reprap.org) page. But I'm always looking for a better source.

Me, I look at the sources. GCodes.cpp in this case. As to an emergency stop, RRF has it. I've never wired one up but it has full support for setting up a E-Stop button. And it will bring things to a stop. Same functionality can be used for Sailfish-style P-Stop hardware.

I can confirm the m109 behaviour, its just pause...

M116 I guess is use with the config G10 ? say you set your G10 stanby temp at 200 and call a M116 P0 H1, the firmware gonna look at the stanby temp in the config.g for heater 1 of tool 0 and reach it ?

Also do you guys when upload to SD via octoprint have a HUGE waiting time when the file is streaming to the radds ? Mine is wireless and it take a HUGE amount of time... we talking hours for a 10MB file. I was wondering if its a normal behaviour or its because of my wireless. My controller are still on the side of my printer but as soon I get my raps128 im gonna put everything under and wont have access to the SD card, unless I wire a external SD card to the radds, so they will be no way to remove that internal SD card so I have to cut down that crazy amount of time octoprint do when uploading file to SD.

@Angelo

Good news! I would buy them from you if I could but since im in north america the shipping is probably better for me if I get them on makerfarm, I guess you dont charge the 19% tax on North America so the price is about the same. Just in case I miss the day they receive it and sell them all, do you have a guess how much the shipping could be to canada east for 5 raps128?

Also any news from your new prototype driver ? are they worth waiting for? im looking at the best possible driver for delta , so the slow movement and best low current zone are what im after ( delta carrier sometime move very slowly and only a few to print a line in front of an axis). Could you tell us whats the new prototype improvement will be ?

Edited 1 time(s). Last edit at 06/01/2016 10:11PM by GroupB.