Results 21 to 30 of 48
Hybrid View
-
11-25-2014, 08:01 AM #1
Thanks AbuMaia, I will be printing that soon!
-
11-25-2014, 08:18 AM #2
The new makerfarm supplied nema 17's run cool. I expect they are made a lot closer to AUS than they are to the US. just get the model number , order from hong kong, etc. and it's a short boat ride. I can post a pic of the label if needed but i think Clough42 or someone had a post recently about the spec's of the new motors. As Drone suggested, this is a way better solution rather than putting a fan on every stepper. I can understand if you're very isolated the shipping can be crazy though.
-
11-25-2014, 03:19 PM #3
There isn't an M906 command in Marlin. But there are these two commands:
case 907: // M907 Set digital trimpot motor current using axis codes.
case 908: // M908 Control digital trimpot directly.
-
11-25-2014, 10:44 PM #4
-
11-25-2014, 10:51 PM #5
Be careful what you ask for! You might get it.... I pulled Marlin_main.cpp into Vi (my favorite editor) and started searching. All of the G and M commands are implemented via switch statements with various case: lables. I searched for 906: It wasn't in there. But pretty much (there are exceptions) the case values are in ascending order. I got up into the 900's and this what is there:
Code:case 907: // M907 Set digital trimpot motor current using axis codes. { #if defined(DIGIPOTSS_PIN) && DIGIPOTSS_PIN > -1 for(int i=0;i<NUM_AXIS;i++) if(code_seen(axis_codes[i])) digipot_current(i,code_value()); if(code_seen('B')) digipot_current(4,code_value()); if(code_seen('S')) for(int i=0;i<=4;i++) digipot_current(i,code_value()); #endif #ifdef MOTOR_CURRENT_PWM_XY_PIN if(code_seen('X')) digipot_current(0, code_value()); #endif #ifdef MOTOR_CURRENT_PWM_Z_PIN if(code_seen('Z')) digipot_current(1, code_value()); #endif #ifdef MOTOR_CURRENT_PWM_E_PIN if(code_seen('E')) digipot_current(2, code_value()); #endif #ifdef DIGIPOT_I2C // this one uses actual amps in floating point for(int i=0;i<NUM_AXIS;i++) if(code_seen(axis_codes[i])) digipot_i2c_set_current(i, code_value()); // for each additional extruder (named B,C,D,E..., channels 4,5,6,7...) for(int i=NUM_AXIS;i<DIGIPOT_I2C_NUM_CHANNELS;i++) if(code_seen('B'+i-NUM_AXIS)) digipot_i2c_set_current(i, code_value()); #endif } break; case 908: // M908 Control digital trimpot directly. { #if defined(DIGIPOTSS_PIN) && DIGIPOTSS_PIN > -1 uint8_t channel,current; if(code_seen('P')) channel=code_value(); if(code_seen('S')) current=code_value(); digitalPotWrite(channel, current); #endif } break;
Code:case 350: // M350 Set microstepping mode. Warning: Steps per unit remains unchanged. S code sets stepping mode for all drivers. { #if defined(X_MS1_PIN) && X_MS1_PIN > -1 if(code_seen('S')) for(int i=0;i<=4;i++) microstep_mode(i,code_value()); for(int i=0;i<NUM_AXIS;i++) if(code_seen(axis_codes[i])) microstep_mode(i,(uint8_t)code_value()); if(code_seen('B')) microstep_mode(4,code_value()); microstep_readings(); #endif } break; case 351: // M351 Toggle MS1 MS2 pins directly, S# determines MS1 or MS2, X# sets the pin high/low. { #if defined(X_MS1_PIN) && X_MS1_PIN > -1 if(code_seen('S')) switch((int)code_value()) { case 1: for(int i=0;i<NUM_AXIS;i++) if(code_seen(axis_codes[i])) microstep_ms(i,code_value(),-1); if(code_seen('B')) microstep_ms(4,code_value(),-1); break; case 2: for(int i=0;i<NUM_AXIS;i++) if(code_seen(axis_codes[i])) microstep_ms(i,-1,code_value()); if(code_seen('B')) microstep_ms(4,-1,code_value()); break; } microstep_readings(); #endif
Last edited by Roxy; 11-26-2014 at 08:20 AM.
-
11-26-2014, 08:46 PM #6
My guess is that the Y motor also has more work to do. Anyone know how the weight of the Y bed, heater, glass, and rolling hardware compares to the X-carriage and extruder parts? Plus, as the print grows, the weight that the Y-motor needs to move around keeps going up...
Last edited by printbus; 11-26-2014 at 08:59 PM.
-
11-26-2014, 09:16 PM #7
- Join Date
- Jun 2014
- Posts
- 74
All very good points Printbus. Keeping that in mind it might make sense to look at the part being printed and the orientation it is being printed in. If the part is much narrower in x than y, for the same reason it might make sense to reorient the print to put the longer direction on the x axis.
-
11-26-2014, 09:24 PM #8
I was going to argue that it wouldn't make any difference, but I see your point. Putting the bulk of the print in the X axis would minimize how much movement is required in the Y direction. Interesting thought.
OME - We're just offering you ideas on what could be causing your Y axis issue. You certainly have the right to discard any of the suggestions that are provided.
-
11-27-2014, 03:56 AM #9
No problem with that. This is a discussion, after all. We hope to reach a conclusion that explains the situation.
As to the Mass that the steppers are moving, if you discount the parts common to both X & Y axis units, such as the linear bearings, idler bearings and components, you have to compare the weights of items being moved.
As an approximation, I'd say that the print board and heater on the Y axis are the same as the extruder gear assembly including the hobbed bolt on the X axis. The extra weights are the extruder itself, its cooling fan and the biggy, the extruder stepper motor. A NEMA 17 weighs approximately 11 oz (~300 gm). So, I'd say that the X-axis stepper has to do more Work ( Mass x Acceleration x Distance) than the Y axis.
Drone might have hit on a factor. Originally I had the object sliced so that its length in the X axis direction was greater than in the Y axis direction. I had an unrelated issue with that print (uneven bed), so I re-sliced so that the object was longer in the Y direction than the X direction. That meant that the Y axis stepper had more work to do, and that's when the jump happened.
What I am not satisfied with is that after the jump, the print continued with all subsequent Y positions offset exactly 7 mm from the pre-jump Y positions. The extrusions after the jump were as neat as those before it.
I'm going to run another print tonight to see if room temperature was a factor. It's cooler tonight than on the afternoon that I encountered the problem.
Old Man Emu
-
11-26-2014, 11:29 PM #10
Agreed... There are a couple of corner cases. Like what if the Slicer was pretty much just generating GCode that moved the X Axis. But in general the X & Y movement are going to be similar. The difference is the Y motor is moving much more weight. That is going to factor directly into how much energy is being pumped into the Y motor.
New to 3d printing looking for...
05-20-2024, 12:56 AM in Tips, Tricks and Tech Help