ended up using the jy-mcu, hc 04 version with the bridge step down. even after i read that my board could handle the output power from the ramps, i still needed to add the bridge to drop down the voltage. it was good seeing your setup for the blue tooth, because there are so many different ways shown on how to set up the bluetooth, Thank you.
i now have it hanging and ready to start calibration
I have assembled the hangprinter and electronics. Now is time to configure it, run ropes and add bluetooth antenna later. Still waiting for hubbed gear.
Can someone help me with the code? Are you using just marlin software or you have a firmware updated for hangprinter?
I tested the steppers with pronterface, they turn one direction as other is limited due to limit switches which not installed....
Actually found many warnings (pins redefined) when compiled hangprinter code, however it is uploaded to the mega and ramps. I found my BT HC06 is working on another ramps with generic Marlin firmware but it won`t communicate with hangprinter firmware on Ramps. Maybe something changed or additional settings to make it work. Currently I am connected with serial cable and trying to set the ropes somehow...
My configuration is untached and tried with all firmwares form hangprinter + updated one.
I saw many conversations and links but couldn`t find the issue. It seems to me that mostly not relevant...however when I added the U8glib library the compile errors minimised to 4 from 50. Adding U8Glib to config.h has nothing to do with it however less compile errors seems to me..
Strange, I am not very experienced with Arduino. I hoped anyone had similar issues which could help resolving it.
I am quite familiar with Arduino, basic skills, so yes, chosen correct board, CPU, COM port.
Marlin compiles OK. I have a lot of other small programs with Arduino and all compile well.
Did You install any additional libraries? I guess not, should work without additional libraries..
I tried with older version of IDE and is same. Also installed RC7 for CNC and Laser without problems.
I will try to dowload again from github but I don`t expect changes.
sketch\pins_RAMPS_13.h:37:0: note: this is the location of the previous definition
#define Z_MIN_PIN 18
Skica uporablja 46858 bajtov, kar je (18%) prostora namenjenega programu. Maksimum je 253952 bajtov.
Globalna spremenljivka uporablja 3008 bajtov, kar je (36%) dinamičnega spomina in pušča 5184 bajtov za lokalne spremenljivke. Maksimum je 8192 bajtov.
I commented out
// The pullups are needed if you directly connect a mechanical endswitch between the signal and ground pins.
const bool X_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
const bool Y_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
const bool Z_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
const bool X_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
const bool Y_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
const bool Z_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
// Deltas never have min endstops //#define DISABLE_MIN_ENDSTOPS
Now, no more compile errors. Will have to learn what is this exactly for as I don`t have any endstops?
Ah, that's the line I meant to point you to. Line 369 is a blank one in the repo Configuration.h, sorry for that.
Good to hear it works despite the warnings. Redefines are really un-elegant... The whole firmware is an old Marlin fork, full of warts. When the time comes, I hope to run future Hangprinters on something risc-v based similar to this one: [www.crowdsupply.com]
We have our Hangprinter up and running (almost). After a lots of work on getting the anchor points and calculations correct, the printer is moving the correct X-Y distances with a steady Z height.
The problem we are trying to work out now, is the lines go very tight or slack depending on the X-Y moves. I am going to try taking off the line compensation, and see if thats the portion of the code that needs to be tweaked.
The other problem we are having is when applying power to the printer, the steppers turn on, locking the printer in place. This is great for holding position, but quickly overheats the steppers. I have been through the code, and all the stepper timeouts are in place but the steppers are staying locked in place.
The stepper problem might be with the controller board. To save weight and complexity, I went with a more compact single board MKS Base V1.5 over the standard Ramps. This is my first time working with this controller.
Any input to work out the kinks and start printing appreciated.
Mary, Star of the Sea School
A quick over view of our printer.
-Changed out spool support for a aluminum tubing-I kept breaking the printed version.
-MKS base V1.5 controller.
-Raspberry Pi3 running octoprint for stand alone printing and wifi control of G Code commands.
-on board 12v to 5v converter for Pi3
-E3D volcano with 1.2mm nozzle
Other printers we own.
Prusa MK2(Multicolor upgrade), 2 Printrbot Simples, Printrbot Play, Duplicator i3, Custom Built Delta, And a Monoprice Mini. Not to mention the M3D that I'm using as a doorstop.
Hello Aaron at Fablab Hawaii, and greetings from Norway =)
That's a really nice looking printer, I'm impressed that you've gotten as far as you have without asking more questions here =) Your questions pin down two of the design's weaknesses.
The lines going very tight and very slack on G1-moves probably depends on mis-calibration. The buildup compensation feature might make things worse if its default_spool_buildup_factor or line_on_spool_origo are configured to very bad values, but my first guess is that your configured anchor_a_x, anchor_a_y, etc values are the main source of your problem.
I've written a little about calibration here: [vitana.se] Once you've measured a, b, c, f and s, this page is made to save you some typing: [hangprinter.org]
I'm working on making the machine find anchor_a_x, anchor_a_y, etc by itself. Wrote a little about it on the blog post yesterday: [vitana.se]
Since Hangprinter needs to run with all lines constantly tight to control its position motors will never power down (they'd loose steps if they did). Your best option is probably to reduce the amount of current going to the motor to avoid overheating. (Heat drops off quadratically with decreasing current, and torque falls off linearly.)
What material do you use for the base plate? On my latest build with a PLA base plate, I'm using washers as spacers between the motors and the PLA, to prevent PLA from getting warm and soft. The washers are just barely visible here:
The base plate is printed in PETG. I started off trying ABS for stability and heat resistance. But the line standoffs kept breaking. So I printed out the entire project in PETG, then ended up changing the gears to PLA as the PETG proved to soft and meshed poorly.
Still having no luck with the calibration. The line take-up and let-out to maintain tension are out of sync with the G1 moves. It seems like the take-up and let-out are way to aggressive. I have tried dozens of entries for the anchor distances.
I tried turning off line buildup compensation
// If you want the experimental line buildup compensation feature with your Hangprinter, uncomment this.
//#define EXPERIMENTAL_LINE_BUILDUP_COMPENSATION_FEATURE //****turned off for testing*****
But get the following error
Marlin_main.cpp: In function 'void process_commands()':
Marlin_main.cpp:1043: error: 'spool_buildup_factor' was not declared in this scope
spool_buildup_factor = code_value();
'spool_buildup_factor' was not declared in this scope
I will chase down that error and try to run without line compensation if I can't isolate where my problem is.
I have the following questions to try and get the calibration right. I have 2.44 sq. meter working area. I hope this is enough.
1. In measuring the A,B,C anchor points, the Marlin code and the Hangprinter Calibration Calculator says, or shows from "origo". I assume this means origin x=0,y=0,z=0. Do you measure from the anchor hooks to the origin 0,0,0 or to the base plates fish eyelets? I have tried both.
2. In the Marlin code it states "#define ANCHOR_D_Z 2295.0 // measured along vertical line, from fish eye to anchor point". But in the Cali Calculator it seems to imply this measurement is from origin to ceiling eyelets. I have tried both.
3. On the ABC spools I am using a single line out to the anchors, looping through both eyes and then back to the spool. Is this correct? I notice that with this arrangement the line loop lets the base plate rotate slightly. The D spool has 3 lines running out through the eyelets up to the ceiling hooks and back to the plate. Is this correct? With that setup are the following Marlin settings correct?
// Mechanical advantage in each direction needed for dynamic step/mm calculations
// One pulley along each line gives halved forces and doubled distances
#define MECHANICAL_ADVANTAGE_A 1
#define MECHANICAL_ADVANTAGE_B 1
#define MECHANICAL_ADVANTAGE_C 1
#define MECHANICAL_ADVANTAGE_D 2
// Action points in each direction needed for dynamic step/mm calculations
#define POINTS_A 2
#define POINTS_B 2
#define POINTS_C 2
#define POINTS_D 3
4. If I want to change the take-up, let-out to G1 move ratio. What variable would make the change. You mention the "default_spool_buildup_factor or line_on_spool_origo". I will work on those today or next weekend when I have time again.
For reference the current numbers I have for the anchor settings
1 & 2: Calibration calculator assumes measurement to origo. Output values (ANCHOR_A_X, etc) are from eyelet.
3: A little allowed rotation is ok. There's no right and wrong when choosing mechanical advantage. You describe single line from every eyelet, which means mechanical advantage of one. It should work ok.
If both let-out and take-in are way too aggressive, then steps_per_radian is probably wrong (too large by a factor of 2, 4, 8 or 16). If you don't use the experimental line buildup compensation, then default_steps_per_unit is wrong.
What amount of microstepping are you using? Configuration.h assumes 1/16 microstepping.
Are there any directions for the current method of attaching the line to the z spool? i have tried to tie each of the three lines to the spool then run them to the ceiling and back to tie them of to each of the three sides, using three loops. i seem to have made a mess of it and don't really have a good way to level it.