Welcome! Log In Create A New Profile

Advanced

XYZ Moves Only One Direction After FW/HW Upgrade

Posted by ArgoEC3D 
XYZ Moves Only One Direction After FW/HW Upgrade
June 23, 2020 06:32PM
I am attempting to complete upgrades on Creality 3D printers at the University where my wife works. They just got them last year, and with COVID19 the student that was setting them up never finished before graduating. I know very little about 3D printers, other than what I have learned over the last 10 days trying to upgrade this Ender 3. I have a good electronics background, design my own circuit boards for my electronics projects, and have done some Arduino programming.

No idea what version of Marlin it originally ran, it may have already been re-flashed before I got it. I downloaded Marlin 1.1.9.1, and utilizing the vanilla Ender 3 .h files, successfully compiled the hex using Arduino IDE on my Linux laptop. I then added the modifications for the BLTouch sensor and E3D V6 hotend to the .h files. I did not want to loose the beeper, so I removed the cap at EXT-A2 (board version 1.1.3) and installed a header to use A2 (pin 35 according to a reverse engineered schematic from Mr. Riedel, and ATMEGA1284P pinout) for SERVO0. I set SERVO0 pin to 35, then successfully compiled the hex for this, and installed it via ISP.

The system boots, displays the proper version, displays the proper custom machine name, and has all the proper settings and menus. The BLTouch self tests, but does not extend or retract from the menu. The axes also all move in only one direction, towards maximum, whether I turn the encoder knob left or right. When trying to home the system the same thing happens, X and Y move towards maximum. They do stop when I depress the endstops, however.

I have attached the .h files I edited, and the resulting hex if anyone is brave enough to load it. If there are any other files you wish to see, please let us know.

Not ArgoEC3D
Attachments:
open | download - Configuration.h (70.2 KB)
open | download - Configuration_adv.h (69.7 KB)
open | download - Marlin.ino.sanguino.hex (356.5 KB)
Re: XYZ Moves Only One Direction After FW/HW Upgrade
June 24, 2020 01:18AM
There are standard configuration files for newer marlin 2 for Creality machines [github.com]

Even if you don't use Marlin 2, you can gleam valuable information from the files.

for eg you have

#define INVERT_X_DIR false
#define INVERT_Y_DIR false
#define INVERT_Z_DIR true

but the examples have

#define INVERT_X_DIR true
#define INVERT_Y_DIR true
#define INVERT_Z_DIR false
Re: XYZ Moves Only One Direction After FW/HW Upgrade
June 24, 2020 09:18PM
Marlin 2 takes too much room. I swapped the INVERT settings because I thought it was moving as if reversed. When that did nothing I checked further, and that is when I found that the axes move the same direction no matter what way I turn the knob. I have gone over the two configuration files, and variants I have found across the internet. Even "vanilla" configurations from different people do not exactly agree. It will take me 2-3 weeks to go over all of the other files, if not longer, to look for issues there.
Re: XYZ Moves Only One Direction After FW/HW Upgrade
June 24, 2020 10:27PM
You need to actually test things..
Use gcode... and use a control program (eg pronterface)
LCD are for working machines not really for diagnosing issues.

for eg

If you can only move in 1 direction there are only a few possible causes.

the most probable is faulty endstops
Send the machine a M119 (endstop status)
Any endstop that is activated should show TRIGGERED, and any endstop that are not should say OPEN
If these are reversed you can invert them in firmware, if they arent changing check you have pullups enabled.. If its neither of these its one of the following.



Other causes are:
using wrong motherboard, so firmware is looking at wrong pins for the endstops. and stepper driver direction lines.
endstops unplugged (this is normally configured to cause them the be triggered as a safety feature)
endstops plugged in wrong place.
Re: XYZ Moves Only One Direction After FW/HW Upgrade
June 28, 2020 08:06PM
Single-direction movement of axes was caused by using pin 35 (A2) for SERVO0, don't know why yet. A2 is one of the alternate lines listed to use for the BLTouch. I have moved SERVO0 back to pin 33 (Beeper), which uses the adapter board in the Creality BLTouch kit that breaks out pin 33 on the LCD cable. X and Y axes home now works perfectly, not so much the Z axis... Don't like loosing the beeper, and don't like that the cover fan no longer fits because of the height of the adapter board. Had to turn the cover over, swap the fan wires, and now need to make a cover for the fan. And this kit was from Creality...

I know little about gcode, and nothing about control programs such as Pronterface. I am learning gcode, and will have to look into a control program. The LCD with certain menus enabled does serve as a basic troubleshooting tool, however. I knew the stop switches and axes were working prior to these mods, with vanilla 1.0.9.1. As was the move axes functions from the LCD.

I was going to write a pintest program for the board but discovered I pulled a DOH!, and connected the BLTouch backwards when swapping back to the pin 33 kit. So, all is on hold until I get the new BLTouch in. A project I expected to take a couple of weekends to help my wife and the University has now turned in to over a month of weekends... The student that was working this project could not finish due to COVID restriction from campus, and has now graduated.

My wife wants Octoprint installed on a Raspberry PI and connected to the printer, will this do the same as Pronterface? Pronterface seems to have changed names to Printrun.
Re: XYZ Moves Only One Direction After FW/HW Upgrade
June 28, 2020 10:35PM
Pronterface is a suit of tools of which printrun is one of them.

Yes Octoprint can be used as equivalent to Pronterface.
Re: XYZ Moves Only One Direction After FW/HW Upgrade
July 06, 2020 11:44PM
OK, found part of my problem; using wrong pin # for program. I found the MightyCore ATMEGA1284-to-Sanguino pinout, but it still does not seem to be quite right. The Ender-3 uses the Sanguinololu I believe, with a TQFP ATMEGA1284P IC. Where can I find a pinout for this? Is the MightyCore ATMEGA1284 pinout actually correct for the 1284P, and I am still missing something? When I try to assign pin 29 (A2/PA2/ADC2/PCINT2/ IC pin 35) to SERVO0, it shows red as if not defined. Pin 29/A2 is completely unused on the Ender-3 motherboard, the EXT-A2 location on the board does not even have a connector soldered in place, just a cap between VCC and GND. I have attached the reference documents I am using to try and figure this out. 1284 pdf was too large to attach.
Attachments:
open | download - Ender3_rev_eng_schematic.PDF (714.5 KB)
open | download - 1284 IC to Arduino Pin Designations.jpg (256.7 KB)
Re: XYZ Moves Only One Direction After FW/HW Upgrade
July 07, 2020 01:00AM
Mighty core is not the standard pin outs names. its an alternative system.

Enable pins_debugging in your Configuration_adv.h and send the machine a m43 It will tell you what is on each pin.
look into gcode M42 allows you to manually control unprotected (not in use by firmware) pins
There is also more to M43

As for pinout I'm and fairly sure the atmel to arduino mapings are identical to the DIP version.

// ATMEL ATMEGA644/ATMEGA1284 / SANGUINO
//
//                        +---\/---+
//            (D 0) PB0  1|        |40  PA0 (AI 0 / D31)
//            (D 1) PB1  2|        |39  PA1 (AI 1 / D30)
//       INT2 (D 2) PB2  3|        |38  PA2 (AI 2 / D29)
//        PWM (D 3) PB3  4|        |37  PA3 (AI 3 / D28)
//     SS PWM (D 4) PB4  5|        |36  PA4 (AI 4 / D27)
//       MOSI (D 5) PB5  6|        |35  PA5 (AI 5 / D26)
//       MISO (D 6) PB6  7|        |34  PA6 (AI 6 / D25)
//        SCK (D 7) PB7  8|        |33  PA7 (AI 7 / D24)
//                  RST  9|        |32  AREF
//                  VCC 10|        |31  GND
//                  GND 11|        |30  AVCC
//                XTAL2 12|        |29  PC7 (D 23)
//                XTAL1 13|        |28  PC6 (D 22)
//       RX0 (D 8)  PD0 14|        |27  PC5 (D 21) TDI
//       TX0 (D 9)  PD1 15|        |26  PC4 (D 20) TDO
//  INT0 RX1 (D 10) PD2 16|        |25  PC3 (D 19) TMS
//  INT1 TX1 (D 11) PD3 17|        |24  PC2 (D 18) TCK
//       PWM (D 12) PD4 18|        |23  PC1 (D 17) SDA
//       PWM (D 13) PD5 19|        |22  PC0 (D 16) SCL
//       PWM (D 14) PD6 20|        |21  PD7 (D 15) PWM
//                        +--------+
//
Re: XYZ Moves Only One Direction After FW/HW Upgrade
July 07, 2020 01:09AM
Oh and creality provide the circuit diagrams
[github.com]
Re: XYZ Moves Only One Direction After FW/HW Upgrade
July 08, 2020 06:42PM
Dust, pretty useful stuff, this gcode. Thank you. Yes, I have that circuit diagram, I'm a little leery of stuff from Creality, with my experience with them so far. The schematic from R. Riedel seems much better documented, for example. Any idea why I cannot assign pin 29 to SERVO0 in v1.1.9.1? It is red in IDE when I assign it, and if I remember right that indicates it is undefined? I'll get this thing connected to octoprint and do some gcode exploration, as soon as I finish fixing the faults (poor solder, poor grounds, etc.) on the board. Making a few mods I found as well, such separating FAN and FAN1, and making FAN1 24V constant power for the hotend.
Re: XYZ Moves Only One Direction After FW/HW Upgrade
July 16, 2020 10:49PM
OK. The printer is working, the Pi is connected, and OctoPrint running. I have a debug firmware installed, and the output of M43 I is as follows:

Send: M43 I
Recv: PIN: 0 Port: B0 E0_DIR_PIN Output = 0
Recv: PIN: 1 Port: B1 E0_STEP_PIN Output = 0
Recv: PIN: 2 Port: B2 Z_DIR_PIN Output = 1
Recv: PIN: 3 Port: B3 Z_STEP_PIN Output = 0 TIMER0A PWM: 0 WGM: 3 COM0A: 0 CS: 3 TCCR0A: 3 TCCR0B: 3 TIMSK0: 5 overflow interrupt enabled
Recv: PIN: 4 Port: B4 AVR_SS_PIN Output = 0 TIMER0B PWM: 128 WGM: 3 COM0B: 0 CS: 3 TCCR0A: 3 TCCR0B: 3 TIMSK0: 5 compare interrupt enabled overflow interrupt enabled
Recv: . FAN_PIN Output = 0
Recv: . SS_PIN Output = 0
Recv: PIN: 5 Port: B5 AVR_MOSI_PIN Output = 1
Recv: . MOSI_PIN Output = 1
Recv: PIN: 6 Port: B6 AVR_MISO_PIN Input = 1 TIMER3A PWM: -25536 WGM: 0 COM3A: 0 CS: 2 TCCR3A: 0 TCCR3B: 2 TIMSK3: 2 non-standard PWM mode compare interrupt enabled
Recv: . MISO_PIN Input = 1
Recv: PIN: 7 Port: B7 AVR_SCK_PIN Output = 0 TIMER3B PWM: 0 WGM: 0 COM3B: 0 CS: 2 TCCR3A: 0 TCCR3B: 2 TIMSK3: 2 non-standard PWM mode
Recv: . SCK_PIN Output = 0
Recv: PIN: 8 Port: D0 RXD Input = 1
Recv: PIN: 9 Port: D1 TXD Input = 0
Recv: PIN: 10 Port: D2 BTN_EN2 Input = 1
Recv: PIN: 11 Port: D3 BTN_EN1 Input = 1
Recv: PIN: 12 Port: D4 HEATER_BED_PIN Output = 0 TIMER1B PWM: 0 WGM: 4 COM1B: 0 CS: 2 TCCR1A: 0 TCCR1B: 10 TIMSK1: 2 non-standard PWM mode
Recv: PIN: 13 Port: D5 HEATER_0_PIN Output = 0 TIMER1A PWM: 2000 WGM: 4 COM1A: 0 CS: 2 TCCR1A: 0 TCCR1B: 10 TIMSK1: 2 non-standard PWM mode compare interrupt enabled
Recv: PIN: 14 Port: D6 E0_ENABLE_PIN Output = 1 TIMER2B PWM: 0 WGM: 1 COM2B: 0 CS: 4 TCCR2A: 1 TCCR2B: 4 TIMSK2: 0
Recv: . X_ENABLE_PIN Output = 1
Recv: . Y_ENABLE_PIN Output = 1
Recv: PIN: 15 Port: D7 X_STEP_PIN Output = 0 TIMER2A PWM: 0 WGM: 1 COM2A: 0 CS: 4 TCCR2A: 1 TCCR2B: 4 TIMSK2: 0
Recv: PIN: 16 Port: C0 BTN_ENC Input = 1
Recv: PIN: 17 Port: C1 LCD_PINS_ENABLE Output = 0
Recv: PIN: 18 Port: C2 X_MIN_PIN Input = 1
Recv: . X_STOP_PIN Input = 1
Recv: PIN: 19 Port: C3 Y_MIN_PIN Input = 1
Recv: . Y_STOP_PIN Input = 1
Recv: PIN: 20 Port: C4 Z_MIN_PIN Input = 0
Recv: . Z_STOP_PIN Input = 0
Recv: PIN: 21 Port: C5 X_DIR_PIN Output = 0
Recv: PIN: 22 Port: C6 Y_STEP_PIN Output = 0
Recv: PIN: 23 Port: C7 Y_DIR_PIN Output = 0
Recv: PIN: 24 Port: A7 (A-7) TEMP_0_PIN Analog in = 980
Recv: PIN: 25 Port: A6 (A-6) TEMP_BED_PIN Analog in = 1023
Recv: PIN: 26 Port: A5 (A-5) Z_ENABLE_PIN Output = 1
Recv: PIN: 27 Port: A4 (A-4) SERVO0_PIN Output = 0
Recv: PIN: 28 Port: A3 (A-3) LCD_PINS_RS Output = 0
Recv: PIN: 29 Port: A2 (A-2) Analog in = 1021 Input = 0
Recv: PIN: 30 Port: A1 (A-1) LCD_PINS_D4 Output = 1
Recv: PIN: 31 Port: A0 (A 0) LCD_SDSS Output = 1
Recv: . SDSS Output = 1
Recv: ok

I note Pin 29/A2 is unused/unknown. I do not know what this means for sure, but I suspect it means that pin 29 is undefined in the Marlin code. This would be why I cannot use it for SERVO0. There is a bit of this output I do not understand, but I am looking into it. If I am correct, how can I go about defining pin 29?
Re: XYZ Moves Only One Direction After FW/HW Upgrade
July 16, 2020 11:10PM
"I note Pin 29/A2 is unused/unknown."

It means that it is unassigned to anything in marlin. (or its an obscure things that m43 doesn't know about, but servos arn't obscure. )
It also means you can use m42 P29 S{number 0-1 for non pwm) on it.

If you look at the output you have SERVO0_PIN on 27. (but I don't think thats a PWM capable pin either)


Recv: PIN:  27   Port: A4 (A-4)  SERVO0_PIN                  Output = 0
Recv: PIN:  29   Port: A2 (A-2)  unused/unknown   Analog in =  1021   Input  = 0
Re: XYZ Moves Only One Direction After FW/HW Upgrade
July 17, 2020 07:27PM
OK, unassigned or unknown. Why? Where? I do not care if the lines are PWM capable, they are used for 0/1 only for SERVO0 (BLTouch). And what is "Analog in = 1021 Input = 0"? There is no input to pin 29, it is floating. I suppose the analog input could be an indication of this, but the threshold is not reached for a logic 1... I could try grounding it, this would verify functionality... tie it to 5VDC as well just to be sure... What I really need to know is how to tell Marlin this pin exists, and to use it for SERVO0. Pin 27 works fine, but uses a ridiculous adapter card on the LCD connector to break it out, that forces you to raise the cover so the fan will fit. Not to mention that there is no keying of the connectors so they can be connected out of alignment or backwards.
Re: XYZ Moves Only One Direction After FW/HW Upgrade
July 19, 2020 06:16PM
Well, traced the whole evolution of pin assignments from Sanguinololu v1.1 to Creality Melzi, found out that there are multiple functions assigned to some pins, and why. I am guessing it is wrong, but causes no issues as long as more than one of the assignments is not used I suppose. Some of the assignments also seem to be similar functions.

I cleared up an assignment I made in configuration_adv that was keeping me from using pin 29, and replaced a missing # before a define that I deleted at some point. The BLTouch is now connected to A2, the Creality adapter card is gone, the cover is back in it's proper place,and the system is fully functional. This part is now completed.
Sorry, only registered users may post in this forum.

Click here to login