Quoteuncle_bob As mentioned earlier ... you probably don't want to get the FET's switching a whole lot faster than half a microsecond or so. There will not be any real gain in power dissipation. The ringing issues will keep power sloshing around for quite a while with fast edges. I don't think we want to get into high current ferrite beads on the leads. Might be useful to scope all the supplies (by ambrop7 - Controllers
My PC and printer PSU are plugged into the same extension cord, they certainly both have a ground connection. And this is actually the issue, because the resistance of the ground connections is low enough to have a significant fraction of the heater current coming back into the PSU negative terminal. And you can't really prevent that, it's just Ohm's law. Better ground (lower resistance) will makby ambrop7 - Controllers
@Cefiar I can't try the wire connection at the moment since I'm lacking a soldering iron, but I don't think it will do much. Let me emphasize that the parasitic voltage only appears when heaters are active, and in particular I believe it's due to a fraction of the current coming out of mosfet S terminals taking an unintended route through the ground traces. I've done some more measurements withby ambrop7 - Controllers
Ok, so I've added another wire to my setup, from where I soldered the existing wire to GND trace (top-left end of the wire in the picture), to the GND pin on the Due board, the one next to Vin (I soldered the wire to the bottom side of the board). I've also fixed the trace I've previously broken on purpose. I now measure thermistor-ground-to-due-ground voltage no more than 0.002V, and temperatureby ambrop7 - Controllers
I've made some progress in debugging my ADC errors. The symptom is easy to reproduce: whenever a heater is on, the ADC readings go up (temp readings go down), permanently, until the heater is turned off. More heaters, and more heater current, produces a higher error. I've been measuring voltage between the ground connection of the thermistors and Due's GND pins next to Vin (presumably these haby ambrop7 - Controllers
I've just tried connecting a Mega with my RAMPS-FD, and it's not working. I've first flashed updated firmware with the right pin configuration, and it boots all right on its own, but as long as the Mega is connected to a RAMPS-FD, it will not boot. The power LED is on but it never starts the firmware. I've left JP101 in the IOREF position, having verified that my Mega provides 5V on the IOREF piby ambrop7 - Controllers
I've just discovered that the serial problems only appear if the board is connected to the RAMPS-FD, it works all right alone, powered via USB. When it's connected to the RAMPS-FD, it doesn't matter if it's powered via USB or the main power is connected. Additionally, I've tried reading the firmware from the SainSmart's atmega16u2 and flashing it to the Arduino's (including the fuses), and it diby ambrop7 - Controllers
I now have a real Arduino Due and I'm seeing problems with the serial port. It would not work right at 250000 baud. The board->host transfer is all right, but host->board is broke, with lots of errors. But the same firmware works fine on my SainSmart Due. I set the UART->UART_BRGR to 21, and this is actually the perfect value, being equal to 84000000/(16*250000). I've also tried baud 218by ambrop7 - Controllers
About the broken connections, I don't really care, just good that we know it's a manufacturing defect and not something with the design. On another matter, I've been having problems with the ADC ever since. There is very high variance; for example I can see the ADC reading jump from 82/1024 (235C) to 88/1024 (230C), in less than half a second, then back. From what I've observed, it's caused by Fby ambrop7 - Controllers
QuoteCefiar That said, the pull-ups/pull-downs are supposed to kick in when the tristate buffers are "disconnected" in Z mode, so I'm guessing that the tristate buffers are actually somehow loading their outputs when they're not powered. I think the issue is that with VCC unpowered, the pull-ups don't do anything. So if we assume that the DMN2075U will be closed, then the gate of the IRLB8743PBFby ambrop7 - Controllers
I'm wondering if there should be pullups/pulldowns for *all* heaters, as well as stepper enables, in front of the tri-state drivers (not just for FET5/6 which are active-high, unlike everything else). Because guess what happens if the Due is not connected, or VCC fails. Yes, everything is turned on, due to pulldown/pullups on the other side of the drivers. EDIT: yeah pullups won't quite work ifby ambrop7 - Controllers
QuoteCefiar ambrop7: E0-Dir and Z-Min run next to each other, and are on the bottom of the board, next to Pin 21 of the Due. Can you check that they actually put those tracks on the board (it's possible they removed them accidentally), or that they haven't been damaged somehow by their manufacturing process? If this is caused by them putting in too large a hole, I suspect other issues as well,by ambrop7 - Controllers
I've just discovered that my E0-dir is broken. The extruder would always move in the same direction. I've moved the same stepper driver to the E2 slot and it works there.by ambrop7 - Controllers
I've checked my E-stop and it works for all the hardware I use, including X stepper.by ambrop7 - Controllers
@Cefiar I've just checked the datasheet for the default pin state. I/O pins are set to input by default, with pull-up resistors *enabled*. That explains why FET5/6 are being driven. The datasheet also specifies the pull-up resistance to be somewhere between 50k and 150k. So, if a 10k pull-down resistor was added, that would ensure that in the worst case, the voltage will be 3.3*(10/(10+50))=0.55by ambrop7 - Controllers
I have finally received my RAMPS-FD from Geetech. My observations so far are: - It's a bit dirty and missing jumpers (particularly for microstep configuration), as was observed by Dust. No pins were bent. - Bed heater (D8) and first two extruder heaters (D9, D10) work (haven't tested D11). I've installed a heatsink to the bed mosfet (the one from RAMPS). It's running pretty cool; heatsink temperby ambrop7 - Controllers
Quotebobc In practice all that is really needed is some concept of cooperative multitasking and event driven architectures, which is really bread and butter stuff for embedded programmers. And even multitasking is not strictly required. In my APrinter firmware, I'm doing just fine with main loop plus interrupts. Yes, it certainly could be used to reduce response times, particularly with networkby ambrop7 - Controllers
QuoteT3P3 The additional libraries for the RepRap Firmware are here: Hey. Thank you for this information, I'll give it another shot. As far as pins are concerned, in my firmware I use some advanced C++ template metaprogramming to get nice and efficient code; link. Don't mind the Context, Position and other boilerplate. Though this isn't exactly easy to integrate. It would require more templateby ambrop7 - Controllers
QuoteDust annother new board But its the same ARM processor as the Arduino Due, so its firmware should be able to be ported esily to ramps-fd I've given it a quick look but it would need some work. Specifically many files are missing (and I haven't seen docs on where to get them). Additionally, the pin handling is messed up, and it's non-trivial to change pins. The problem is that even thouby ambrop7 - Controllers
Quotekarabas Ok, I agree. Is it possible to port easely the code to discovery? I got this board an year ago by mistake... BTW did you read this thread? About new future ultimaker board Probably. But if you expect me to do it, I'd need the schematic (which doesn't seem to be available), and you'd need to give me one such board, as a gift How did you manage to get this board in the first placby ambrop7 - Controllers
Quoteangelo Maybe i will test R2D2 and aprinter for the RADDS Shield, and maybe the firmware ist better then Repetier? angelo I can't help you with R2D2, the port is being developed by bobc not me. But I can tell you that it's almost trivial to change the pin definitions in APrinter to suit RADDS. I can help you with that if you want.by ambrop7 - Controllers
Quoteangelo Which Firmware is used für the RAMPS-FD? Have fun angelo Reading though this forum turns up: - Bobc's port of R2C2 - APrinter (developed by me) - Perhaps some form of RepetierFirmware, see this post by bobc. I have yet to test R2C2, I only know that my APrinter works reliably (as far as I can tell) on my improvised setup which should be pin-compatible with RAMPS-FD. So I'll just asby ambrop7 - Controllers
QuoteDust Some of the pins are quite bent over. Its obvious this happened at the factory as the 4th pin from the right is far to low and has been soldered in like that! But otherwise the bending of the pins looks very much like someone was carelessly detaching the board from a Due.by ambrop7 - Controllers
@karabas You should also be aware that the baud rate may not actually be the limiting factor, rather, the planning calculations may be. This is much more likely on AVR boards (you were experiencing your problems on AVR, right?). Planning usually involves expensive floating point calculations. And this is where Due does much better, with the high clock frequency as well as 32-bit arithmetic (it doby ambrop7 - Controllers
Quotekarabas If head path is very complicated and speed is high the gcode comand rate is too high and 250000(standart Ultimaker rate) is not enough. So native USB is a must. Yes? I haven't had a single time where it wasn't enough. By the way, APrinter supports SD card printing (in a limited way), and if you're printing anything larger you should be using that. That is not to say native USB willby ambrop7 - Controllers
Quoteuncle_bob When you fix the thermistor tables, think about some sort of "transparent" fix. There are vendors out there supplying tables for their thermistors, but not flowing them upstream. Why they do this - I have absolutely no idea. How to implement such a thing (or if it's worth it) - that's up to you. The problem is that the thermistor tables are generated with a Python script. You needby ambrop7 - Controllers
Quotebobc The erase button is pretty much inaccessible with the RAMPS-FD attached, but the command "stty -F /dev/ttyACM0 1200" will erase the Due and put it into the bootloader. Yes, I read that in the Arduino docs, but for some reason it's not working optimally on my Due (SainSmart) board. The 1200 baud will put it in bootloader, but after flashing, it won't reset, despite bossac sending the reby ambrop7 - Controllers
Quotekarabas Does your code use advantages of the arm? Why only 250000? I have simply implemented the HALs that my firmware depends on (e.g. GPIO, serial port, ADC, timers, SPI). Due to faster CPU and more RAM, it allows much faster max stepping speeds and larger buffers, but otherwise the firmware behaves the same as on AVR. Hardware my firmware does *not* make use of, at least in its currentby ambrop7 - Controllers
Oh, I've fixed the inverted heaters problem in APrinter. I don't think there's anything now preventing it from running on a real RAMPS-FD. @bobc If you find some time could you give APrinter a test on your board? All the instructions are here, including building for Due/RAMPS-FD. You need Linux and the latest gcc-arm-embedded compiler (link in instructions).by ambrop7 - Controllers
Okay, SD card with APrinter/Due works now. Hopefully the RAMPS-FD will fix my spaghetti problemby ambrop7 - Controllers