Show all posts by user
Page 2 of 4
Pages: 1234
Results 31 — 60 of 91
@dc42
I have also wondered about how many moves need to be processed each time. My Apritner firmware does not optimize unnecessary computations, it does a full planning round when it decides to recalculate. When I tried to optimize this (by going back only as far as something changes), I found that it took more cycles on average, so I didn't go with it. Though, this was probably after I implement
by
ambrop7
-
Firmware - experimental, borrowed, and future
Hi Andrew,
Thanks for the interest. The online GUI allows you not only to configure the firmware, but will compile it for you with the click of a button. You receive a zip with the binary that you flash to the chip.
And yet, I have made it particularly easy to compile it yourself - not only that, but to run the web service locally. You will need this if you want to develop the firmware. The pre
by
ambrop7
-
Firmware - experimental, borrowed, and future
Hey,
This is not quite what you asked about, but I will mention a possible way to improve the performance of the planning calculation *in the firmware*. Note that I have implemented this in my APrinter firmware (but the planning there overall may not be faster due to a much different design...).
First let me give a short introduction to the planning stuff. The core of lookahead-based planning a
by
ambrop7
-
Firmware - experimental, borrowed, and future
Hi all,
I have done important development for APrinter since. New features include:
- A web based configuration GUI with a service for compiling the firmware.
- FAT32 read support for SD card printing.
- Laser support, or more generally, PWM outputs with duty cycle controlled proportionally to the speed. You can also hook it up to a fan rather than a laser.
Please feel free to try it out and pr
by
ambrop7
-
Firmware - experimental, borrowed, and future
So, as per request, here's a description of the step time calculation algorithm used in APrinter.
Note that it may have some errors and some details of the implementation may have been left out.
Suppose we want to move in a constantly-accelerated manner, with the following parameters:
X - Length of the move in steps.
T - Duration of the move.
A - Acceleration.
These parameters are generated for
by
ambrop7
-
Firmware - experimental, borrowed, and future
Hey dc42,
I've got a similar algorithm for step timing in my APrinter firmware. Seems like we're both tying to precisely calculate the step times using square roots.
But I think the difference is that I normalize the calculation to the duration of the move (segment with fixed acceleration), and only at the end perform a multiplication with the move-duration to get the final step time. My motivat
by
ambrop7
-
Firmware - experimental, borrowed, and future
My APrinter firmware has supported an arbitrary number of axes ever since. You are however limited by the hardware, AVR is not gonna do, I recommend Arduino Due + RADDS.
Additionally, extruder axes are independent and not constrained by "tool commands" which APrinter does not implement. The recommended naming for extruders is E, U, V. So you have gcode like "G1 ... E10 U20 V15".
Actually, APrinte
by
ambrop7
-
Firmware - experimental, borrowed, and future
I'm creating this thread for general discussion and announcements related to my APrinter firmware.
The full feature list is on the wiki, but here are some things I would like to highlight:
Highly configurable design. Runtime configuration system with configuration store. Delta and CoreXY support. Actually adding a new geometry is rather easy. SD card printing (only sequential blocks). Custom p
by
ambrop7
-
Firmware - experimental, borrowed, and future
I've already got my APrinter firmware running on this.
There were some mysterious problems with the ADC, even though I was using the exact same code as on AT91SAM3X8E. After some experimentation I concluded that the hardware must be broke. So I looked into the errata and there it was:
Quote45.2.2.3 ADC: Trigger Launch Only One Conversion
A start command initiates a conversion sequence of one c
by
ambrop7
-
Controllers
@Mallgan.O
Sorry but I don't know what to say about the design, I'm not an EE. I don't know how the presence of protection components would affect me. For testing, I'm planning to hook it up with wires to my RAMPS-FD or RADDS board (got both). These are designed to work with an attached Arduino Due (AT91SAM3X8E).
by
ambrop7
-
Controllers
@Mallgan.O
I do not have SMD tools.
by
ambrop7
-
Controllers
I think the simplest thing you can to about USB ground loops is to arrange the layout in a way that makes any ground loop current not affect thermistor readings. Like this:
Excuse me for my primitiveness (I'm not an EE), but I do believe this will prevent the issue. The problem with RAMPS-FD is that you don't have the ability to make a thick connection between USB shield and DC- and/or move the
by
ambrop7
-
Controllers
Another note, when one has a reliable stream abstraction, the "ok" responses no longer serve any purpose for flow control. But instead of eliminating them, we could say that the printer can, optionally, send the "ok" responses in real time as commands are physically executed by the printer (or it can just keep the existing semantic, send ok when it's buffered). This would give a very accurate pri
by
ambrop7
-
Firmware - experimental, borrowed, and future
Quotesam0737
> Whenever a packet is transmitted without errors it should be recognized as such by the receiving side.
I don't agree. The either thing could get lost - Maybe the UART TTL line is simple disconnected, maybe the firmware hangs.
The host must be able to recognize this without confusing with lack of activity in high level means (like waiting for G4), maybe due to the lack of respons
by
ambrop7
-
Firmware - experimental, borrowed, and future
Quotesam0737
Your scheme doesn't address data corruption.
What if the command sent was corrupted? The host does not know if the command is received and working (D4/M116 will take a long time), or the command is not received properly such that firmware can't response with an ok.
The further question is what if the firmware response is corrupted.
Yes, I said that my basic protocol idea doesn't add
by
ambrop7
-
Firmware - experimental, borrowed, and future
If you limit to 48 pin SAM3S there are:
SAM3S1A: 64k flash, 16k SRAM: Not enough flash for APrinter, SRAM a bit too little for good performance.
SAM3S2A: 128k flash, 32k SRAM: Okay. APrinter needs about 90k flash for a single extruder setup (105k for dual extruder). But flash may be a problem if at one time APrinter gets fancy features like LCD or FAT.
SAM3S4A: 256k flash, 48k SRAM: Definitely e
by
ambrop7
-
Firmware - experimental, borrowed, and future
QuoteMallgan.O
My design goal is a rock solid HW design as cheap as possible without compromise reliability.
Well, the design goals of APrinter are similar, just in a software sense Anyway I cannot help with hardware, but as soon as you put something together it shouldn't take long to get my code running. Just don't forget we need at least 128k flash (and preferably 256 if the price difference
by
ambrop7
-
Firmware - experimental, borrowed, and future
APrinter doesn't need much in terms of hardware. In order to be able to print, only the following HALs are needed: GPIO, ADC, serial port, clock, timer interrupts. I'll probably just change the SAM3U HALs to work on the SAM3S too.
Each heater needs a digital output pin for the FET and and an analog pin for the thermistor. The digital pin doesn't need to be PWM capable or anything (but you can st
by
ambrop7
-
Firmware - experimental, borrowed, and future
My APrinter firmware already supports SAM3X8E (Arduino Due) and SAM3U4E (4pi board). From looking at the datasheet of the SAM3S1A, it would be an easy port. That wound include serial console over UART or USB and SD card via SPI (but not via HSMCI). However 64k flash will be too little, need at least 128k.
If you're interested I can do the port, but do check the feature list of APrinter first to
by
ambrop7
-
Firmware - experimental, borrowed, and future
Or get one of the ARM based controllers, then it will be no problem to do the transformations in the firmware. My APrinter firmware runs on quite a few ARM based boards (Arduino Due, 4pi, Teensy 3), and it supports custom transforms.
by
ambrop7
-
Firmware - experimental, borrowed, and future
If all you want is to fully utilize the link bandwidth (not limited by round-trip time), and the link is reliable, it is fairly straightforward to solve. At the beginning, have the host query the printer for the total RX buffer size in bytes. We assume that the RX buffer of the printer can be modeled as a simple character based ring buffer, and that each command consumes exactly its length includ
by
ambrop7
-
Firmware - experimental, borrowed, and future
Quotevreihen
I'd just settle for any electronics board and firmware that labels the steppers A/B/C instead of X/Y/Z for a Delta printer! With both Cartesian and Delta settings in one config file, it gets confusing real quick when you're trying to figure out things like whether the X software endstop applies to the tower carriage range of travel or how far the print head is allowed to move in the
by
ambrop7
-
Delta Machines
I can confirm this on my two boards. One is an original Arduino, the "bad" design with the chip near the power connector - this one has Rx problems at 250000 but not 115200 (or it's very rare). Other one is SainSmart, the "good" design with the chip between the headers, and it doesn't have any problems with the serial. The SainSmart however has some problems with resetting on power on or after pr
by
ambrop7
-
Controllers
Quoteturutk
does the sainsmart due have any compatibility issues with this board?
I'm using a SainSmart with a board from Geeetech successfully. My SainSmart board itself is a little bit defective though. When powered on there's a high chance it won't start, and needs the reset button. Similarly, when done uploading firmware, it never resets, and always needs the button.
But otherwise it's work
by
ambrop7
-
Controllers
So I've implemented this in APrinter, see:
Yes, I believe your equations are right, I did the same.
I was "testing" this on my cartesian printer, it does make funny curves. Concerning performance, I've measured that the calculations with this half-delta with single extruder are about 28% slower than my current cartesian setup with dual extruders. So I believe this is still useful, and I may be
by
ambrop7
-
Firmware - experimental, borrowed, and future
Zazza, I suppose you're aiming for a single extruder? If that's the case, it makes a world of difference, and I haven't really taught about it before because I only deal with my double extruder printer It uses less RAM and needs less computation, and then because it uses less RAM we can increase the buffer sizes to make planning more efficient as well as allow more lookahead. When dealing with n
by
ambrop7
-
Firmware - experimental, borrowed, and future
It would also be of some benefit if you had a setup with an SD card (SD-RAMPS). Not only is printing from SD card more efficient than printing from serial as is (in different ways, less processing and no waiting for "ok"), but I've also recently implemented a custom gcode packing format which speeds up calculations by an additional 15%. It might just make the difference in your case See:
by
ambrop7
-
Firmware - experimental, borrowed, and future
Zazza, my firmware does indeed work on atmega2560+ramps1.4, but the coordinate transform requires additional processing (transforming coordinates and splitting segments). It might be too much on AVR. But I'll test soon and maybe try some optimizations, who knows, it might just work all right.
by
ambrop7
-
Firmware - experimental, borrowed, and future
Hey! Nice to see such experiments!
I'm the developer of my APrinter firmware, and I've recently added experimental delta support. Well, that may not seem useful to you, but really it is! That's because my firmware is designed for arbitrary coordinate transforms, and it is almost trivial to define your own coordinate transform by making a custom transform class and defining some functions!
See t
by
ambrop7
-
Firmware - experimental, borrowed, and future
Hello!
I've been working for some time on my APrinter firmware, for those who haven't noticed it yet. This post is about the latest addition, which is support for a custom packed binary encoding of g-code. The current situation is:
- The encoding format is documented.
- There's a python script which does the packing.
- The APrinter firmware includes support for printing packed gcode from SD car
by
ambrop7
-
Firmware - experimental, borrowed, and future
Page 2 of 4
Pages: 1234