AD5X unused header pinouts

[SunX99]

Documenting the unused or unpopulated headers on the AD5X mainboard. Voltage and logic results, if possible, and programming interfaces.
Noted revisions:

• FFP0302_Main_Board_V3.0.0 2024-9-22

[SunX99]

Voltage Test Results

***In voltage test, I am using an auto-ranging voltmeter set in DC-mode. For each header I place negative lead on GROUND and test each PIN with the positive lead looking for a voltage measured in volts. This is done with the printer ON and at idle (no print running, no heat). If there is no GROUND marked I will use a known GROUND from another header. To test GROUND I will do a continuity test between a known ground and the pin in question, confirming a common ground link between the two.

**I looked for silkscreened names of headers, and if not found, what I assumed to be the "Jxx" identifier for it.

KEY
✅ Voltage was successfully measured and amount recorded
🚫 No voltage found
⚠️ Warning, a higher voltage was found, use caution attaching logic analyzers or TTL readers set for 3.3v or 5v.

Identifier	PIN 1	PIN 2	PIN 3
J13	GND	TX	RX
RESULTS	✅ GND	🚫 N/A	🚫 N/A

Identifier	PIN 1	PIN 2	PIN 3	PIN 4
DEBUG	VCC	TX	RX	GND
RESULTS	✅ +3.3V	🚫 N/A	🚫 N/A	✅ GND

Identifier	PIN 1	PIN 2	PIN 3	PIN 4
SWD	VCC	SWCLK	SWDIO	GND
RESULTS	✅ +3.3V	🚫 N/A	🚫 N/A	✅ GND

Identifier	PIN 1	PIN 2	PIN 3	PIN 4	PIN 5	PIN 6
JTAG (J19)	VCC	TMS	TDI	TDO	TCK	GND
RESULTS	✅ +3.3V	🚫 N/A	🚫 N/A	🚫 N/A	🚫 N/A	✅ GND

Identifier	PIN 1	PIN 2	PIN 3	PIN 4	PIN 5	PIN 6
J29	GND	GND	RX	TX	24V	24V
RESULTS	✅ GND	✅ GND	🚫 N/A	🚫 N/A	⚠️ 24V	⚠️ 24V

[SunX99]

Logic Analyzer Results

For Logic Analyzing, I am using a discount generic USB LA tester. Connecting the header's GND to GND on the reader, then assigning the other pins to reader pins on the device (0-7). Omitting pins that have confirmed voltage. Using sigrok pulse view, I am starting a recording at 1mhz, 1t samples, confirming the pins are showing a flatlined signal and then powering up the printer via the master switch on the back. After recording for a 60 secs or so through the bootup sequence I terminate the recording and review.

10/27/25 - LA testing was disappointing. No pulses could be witnessed on the DEBUG, JTAG, or J13 headers during boot up sequences.
Ended the night with testing the LA device on the IFS ports. Was able to confirm pulses are found on the lower two pins at regular intervals, indicating a RX/TX style communication.

[ninjamida]

Would chaining them work? I know RS485 in general can be if the devices support it, but would they have the support?

At any rate, I’m prepared for the possibility that they can’t be chained. Got the parts needed to handle five RS485 connections (four IFSes + upstream to the printer).

I don’t know if it matters whether the IFSes remain powered when the printer isn’t? They wouldn’t receive any commands so I’d think they just sit there idle anyway.

I want to keep this fairly tidy, so I don’t really want to be running extra cables off the PSU. I’d rather go with either a DC jack, or powering it from the IFS socket.

Though one thing that crosses my mind is - 0.2A would be their peak usage, right? If so, it’s not like all four will be active at the same time. Aside from releasing the spools, I don’t think there’s any situation when more than one would be moving at the same time; and that can also be run one at a time if need be. So perhaps running all four off the socket is fine.

The main problem is I don’t plan to use more than two myself. I can test that port 3 and 4 work, but I can’t test that using four at once really does work.

Gonna need to mod my enclosure a bit too… bonus side effect I guess, even if I don’t succeed with the dual IFS mod, it’ll mean all the parts are there for a left IFS mount build of Torreva for anyone who wants that.

[VoronKor]

Would chaining them work? I know RS485 in general can be if the devices support it, but would they have the support?

At any rate, I’m prepared for the possibility that they can’t be chained. Got the parts needed to handle five RS485 connections (four IFSes + upstream to the printer).

I don’t know if it matters whether the IFSes remain powered when the printer isn’t? They wouldn’t receive any commands so I’d think they just sit there idle anyway.

I want to keep this fairly tidy, so I don’t really want to be running extra cables off the PSU. I’d rather go with either a DC jack, or powering it from the IFS socket.

Though one thing that crosses my mind is - 0.2A would be their peak usage, right? If so, it’s not like all four will be active at the same time. Aside from releasing the spools, I don’t think there’s any situation when more than one would be moving at the same time; and that can also be run one at a time if need be. So perhaps running all four off the socket is fine.

The main problem is I don’t plan to use more than two myself. I can test that port 3 and 4 work, but I can’t test that using four at once really does work.

Gonna need to mod my enclosure a bit too… bonus side effect I guess, even if I don’t succeed with the dual IFS mod, it’ll mean all the parts are there for a left IFS mount build of Torreva for anyone who wants that.

No, it won't work. RS-485 communicates without using addresses. This means connecting multiple IFS in parallel will cause data collisions. Also, Sergey didn't add the ability to connect a second IFS; you'll have to rewrite the ZMOD_IFS modules yourself to work with more than one MMU module.

[ninjamida]

Alright, I won’t waste time on a chained setup then.

Yes, I’m aware I’ll need to add the support to zMod myself. I already have a general idea of how I’ll approach this, I’ll figure the specific details out as I go.

[ninjamida]

I finally got around to some hands-on testing rather than just theory last night, and successfully constructed a setup where I wrote commands into the MicroPython debug console for my RP2040, and it transmitted those commands to an IFS which successfully executed them.

One gotcha I ran into: the A/B lines on the IFS are inverted compared to the A/B lines on the MAX3485 board I used. (EDIT: No, they're not. It's the cable I was using that's inverted.)

Seperately, I've tested powering the RP2040 (via stepdown) from a 24V input source. This will allow having only a single power input, or in the case of a smaller setup (2-3 IFSes), simply getting the power from the printer's IFS port.

The RP2040 has two hardware UARTs, plus eight PIO state machines that can be used to create four more UARTs. This is enough for the upstream connection (on a hardware UART), and five IFSes. I doubt anyone is going to want more than this - but it also feels like it would be trivial to allow connecting another splitter to extend the setup. The only issue is logistics around channel numbering - but I feel like this can easily be resolved if the second splitter either (a) has a dedicated, seperate port (perhaps using the second hardware UART for this, and the four PIO UARTs for the actual IFSes), or (b) must be connected to the 4th port specifically.

[ninjamida]

No luck with the state machines… but instead came up with a hack to connect all the IFSes to a single hardware UART. Have successfully sent and received data this way with two IFSes connected.

I expect I’ll have this fully working within a week.

[VoronKor]

I'm using Google Translate.

Okay, you're probably interested in the unsoldered connectors. I'll explain the ones shown in the photos.
The 5X board was designed to be universal for the 5X and Glider 4. But the board itself is also full of 5M roots. There's a three-pin UART next to an unsoldered button. This should be the debug connector for a separate microcontroller (MCU) responsible for turning the 3D printer on and off via a button on the display or a command from the interface. This module is inherited from the 5M PRO motherboard.

DEBUG - This should only contain information during board startup. It will mainly report how the kernel loaded and whether USB was found.
SWD - the MCU programming connector on the mainboard, in our case, the Nation N32G455Rel7. It can be used for programming via the programmer or independently, SWDIO - PA13, SWDCLK - PA14. For example, you can connect an additional limit switch or a NeoPixel backlight here.
JTAG (J19) is also a programming connector, and it's labeled next to it that it's related to the extruder. However, our extruder is connected via RS232, so I think this is untapped potential from the Glider 4. Looking through its error codes, I discovered that it should have more than two heads and an active thermal chamber.
J29 RESULTS - I can't say for sure here. I'm just guessing, but based on your pinout description, it was intended to be compatible with the 5M head board. It also has a 6-pin connector: GND-GND-RX-TX-24V-24V, on the RS232 connector itself. It either goes in parallel to the head connector or is launched by the second channel, since the MAX3232 has 2 receive and transmit channels, while we only use 1.

[SunX99]

Ah this is great! Thank you so much @VoronKor for the details!
The more I read about the busybox OS build and the Ingenic x2600 it seems the debug and uart headers can be disabled, which is counterproductive to the indent of having a debug header for trouble shooting. I think I did read that it's possibly a 1.8v signal and not 3.3v and possible why the level analyzer didn't pick it up. Something else to try later.

[VoronKor]

@SunX99 , It writes information there upon startup. I don't know when you connected the logic analyzer, before or after the printer started. But if the printer reaches the "initializing" prompt, the logic analyzer won't see anything. The printer will enter password mode, which is known only to the manufacturer. The baud rate of this connection is 115200.

[VoronKor]

On Sunday, I'll be able to see what's going on there and attach a screenshot. I'm sure there are standard 3.3V signals there. But if you disable data transfer, you'll get a great free UART for our microcontrollers. For example, you could connect control of the heating chamber heater or another IFS.

[SunX99]

Some other research I finished-
The MOSFET (assumed) for the PCB-FAN is: NCE4060K
It handles up to 40v (which is a good overhead for the 24v) but is thought to be overkill with a 60amp rating. The pad next to it (assumed) for the missing Filter-FAN-IN header is the same size. Putting in an appropriate MOSFET to match would allow trigging this fan via software.
Visually it might be missing something at D22, to match D25, but that might just be an LED. R215 and R220 appear to be unpopulated.

[iamt4nk]

Thanks for this, this is really great. I'm attempting to do something very similar, but this is my first project doing any electrical wiring like this. I have a particle exhaust fan that I want to attempt to wire to this, the fan is 5V as it is USB so i'm going to add a buck converter into the mix to bring it down from 24V to 5V after the MOSFET module. my main question here is, what exactly is the cord labeled FAN going to the voltage switch? My other question is, were you able to get this running with GCODE? I've attempted to enable an "exhaust fan" in my klipper config and then send power to it and read the voltage from the lower left pad like you described. I'm not getting any voltage readings when attempting to look at this with my voltage meter (although it is a very cheap one so I'm not sure how much I can trust it).

If you have any suggestions I'm all ears. I'm trying to research this as much as possible before actually touching it.

[michaelalanchase]

Thanks for this, this is really great. I'm attempting to do something very similar, but this is my first project doing any electrical wiring like this. I have a particle exhaust fan that I want to attempt to wire to this, the fan is 5V as it is USB so i'm going to add a buck converter into the mix to bring it down from 24V to 5V after the MOSFET module. my main question here is, what exactly is the cord labeled FAN going to the voltage switch? My other question is, were you able to get this running with GCODE? I've attempted to enable an "exhaust fan" in my klipper config and then send power to it and read the voltage from the lower left pad like you described. I'm not getting any voltage readings when attempting to look at this with my voltage meter (although it is a very cheap one so I'm not sure how much I can trust it).

If you have any suggestions I'm all ears. I'm trying to research this as much as possible before actually touching it.

The Fan header is just a header I wired in to connect my fan, which is on the back panel to cool the electronics, so it needs a connector to make the panel easy to remove.

I think I did see a signal on the FET pad with a multimeter (or I would not have wired it up), when the correct pin is configured in klipper. I might have looked with a Cro as it's a PWM signal depending on the speed you set for your fan, but on should be 0v or 5V, and off should be the opposite, with varying PWM in between.

[iamt4nk]

Thanks for this! I found out that the PLA_FAN header is actually already populated and I just have to figure out the wiring without soldering directly to the board. So i'm probably going to go that route., just makes a lot more sense, but I'll still use the optocoupler and the buck converter to step it down. I appreciate your response!

[elvinhaak]

Thanks for this! I found out that the PLA_FAN header is actually already populated and I just have to figure out the wiring without soldering directly to the board. So i'm probably going to go that route., just makes a lot more sense, but I'll still use the optocoupler and the buck converter to step it down. I appreciate your response!

Be careful with putting a buck-converter behind a PWM-controlled output. You could ofcourse use the coupler to switch a pre-regulated voltage but it will not work well the other way round.
I' d rather use a 24V fan then making it more difficult then needed.

[nicovil]

The FET module you mentioned here required you to add a 3.3k resistor because they put the indicator led in series with the PWM input resistance, so that led decreases the PWM voltage and that's why adding that 3k3 resistor in parallel fixed that issue. There are other better quality modules that I ordered and I'm waiting to test this (amazon link here). For this module I found the schematics and confirmed that the indicator led is in the mosfet side (after optocoupler) so it doesn't affects the input voltage at all and should not affect the 3.3v logic of printer's MCU to work.
Also the AOD4184 has very small Rds, and works with 40V 50AMP, so it's more than enough for a blower or fan.

[SunX99]

I tested the voltage on the two 2-pin fan connectors last night. Neither had power running to them. I'm assuming they need to be flipped on by a software request after being defined in the printer.cfg.
I un-commented the lines in the printer.base.cfg for pin:PB7, gave it 100% power via the klipper interface and tested the two fan pads mentioned and they did not change.
Just updating the notes here on the finding.

[michaelalanchase]

Has anyone investigated the Filter_Fan_OUT header, and the unpopulated FET Q7 at the bottom of the main board? For some reason I thought that they were associated. I also think PC15 might be the pin that is connected to that FET.
However, in for config files, PC15 is defined for a power button (display_off.cfg).
I have not overridden this yet to test the pin as a PWM output, nor can I find any other reference to this use as a power button (it triggers SHUTDOWN in the button pin macro code.
Anyone know more about Q7, Filter_Fan_Out, PC15 or the power button macro?

[xyzroe]

Hi everyone,
I investigated the mainboard PCB and drew a schematic of the unused, free pins.

The green-labeled pins are unused by default.
What are the conclusions?

1. In order to use the Filter_Fan_OUT and Filter_Fan_IN headers, we need to solder not only FETs, but also diodes, inductors, and capacitors. However, we can also use an external FET module like many others above.
2. There's room for one more stepper driver XR, which gives us five more free pins. I have successfully checked that they are working fine.
   

[output_pin pc10_black]
pin: !PC10

[output_pin pa15_purple]
pin: !PA15

[output_pin pa12_blue]
pin: !PA12

[output_pin pa8_brown]
pin: !PA8

[output_pin pc9_orange]
pin: !PC9

I also found two USB ports on the board. One is on the bottom and goes to port 3 of the USB hub. The other is on the top and goes directly to the CPU, I think.

I also found a TVOC port that seems to be a UART. In my opinion, it goes to the main CPU and is available as S3, but I haven't tested it yet.

[xyzroe]

The data pin of a servo connector goes to PC11. Incidentally, 5V is not present because there is no inductor coil on the back.

[RocketRob06]

these are my current readings for the USB header in the BOTTOM LEFT of the main board (view with board still installed in the AD5X)

5V ~5.05V
GND / GND 0V (confirmed via continuity)
P (D+) ~0.001V
N (D−) ~0.001V

[ninjamida]

Is anything known about J37 (LIDAR-CON)? I would've thought this would be an obvious target given there's already a connector there, but I can't find anything about it (aside from a brief mention from SunX99 about being interested in it).

[nicovil]

What a wonderful work, thanks for sharing all this!
I'm looking to use FILTER_FAN_OUT and FILTER_FAN_IN PWM signals in Q12 and Q14 gates and use them to drive an external mosfet like you suggested here, however I want to use simple modules without optocouplers due to the low voltage used in gate.

Looking @xyzroe PCB, since the mosfet is commuting fan's negative to ground (instead of positive like mosfet modules do), I wonder if it's not easier to connect A mosfet in a custom generic PCB and do something similar of what the mainboard (or as it should be) based in the schematic.

My idea is to basically simulate the whole @xyzroe schema, but without the resistive divisor because it's already in the PCB main board, so we pick the signal directly from there, and replicate the rest of the circuit (1N4007 diode, and the LC filter in +24V)

This seems to be very easy to implement in a PCB, is small, and will simulate the same behavior than the mainboard does, so it should be safe because the mosfet is commuting to ground, and not to 24v and if it becomes in short it will just send microcontroller GPIO to ground, and will not fry the microcontroller.

All this avoids optocouplers and other stuff, and I bet that if the LC filter is removed it should work flawlessly too.

Does that makes sense?

[nicovil]

BTW, I acceded the debug menu of AD5X stock firmware, and found that the auxiliary fans are all commented out, but something weird is that internal_fan and external_fan pins seems to be inverted to what you described here (@xyzroe PCB schema).

chamber_fan is the PLA-FAN one (which someone reported works if configured correctly in stock firmware or in ZMOD).

Did someone here tested that the internal/external fans (PC15 and PA4) are the ones described in @xyzroe schema? Could it be that the firmware (even commented out) have inverted GPIOs configured?

[fan_generic fanM106]                                           
pin: eboard:PB5

#[fan_generic chamber_fan]
#pin:PB7
#hardware_pwm:False

[fan_generic pcb_fan]
pin:PA5

#[fan_generic internal_fan]
#pin:PC15

#[fan_generic external_fan]
#pin:PA4

[ninjamida]

My understanding is that they're backwards in the default config of the 5M Pro, which is likely what that is based on.

It kinda, kinda, makes sense if you think about them being named after the source of the air, rather than the destination. The "internal" one pulls air from the internal area. The "external" one can (depending on the servo) pull air from the external area. No one actually does the servo thing on the 5X (and the back panel wouldn't really let it work anyway) so it seems a lot weirder there.

[nicovil]

If I'm not wrong, EXTERNAL one is the fan in bottom side of the printer, it's an extractor and refreshes the chamber for materials like PLA and PETG.

As you said 5M Pro has a servo to define from where to get the air when the INTERNAL fan (internal circulation) is activated, it can be from chamber or from outside.

Check this configuration file from AD5M Klipper Mod:
https://github.com/xblax/flashforge_ad5m_klipper_mod/blob/master/printer_configs/macros-pro.cfg

There are 3 macros:
AIR_CIRCULATION_INTERNAL: Turn on internal air circulation
AIR_CIRCULATION_EXTERNAL: Turn on external air circulation
AIR_CIRCULATION_STOP: Turn off air circulation

Checking the scripts:

AIR_CIRCULATION_INTERNAL turns off external_fan and moves the servo, that means the air will become from chamber and circulate inside again with internal_fan (passing from upper filter).

AIR_CIRCULATION_EXTERNAL turns on internal_fan, external_fan and moves the servo (to get air from outside). This will extract hot air from the chamber, and use internal fan to get fresh air from outside.

My idea for modding the printer is to put 2 mosfet modules AOD4184 to the gate of the 2 mosfets (internal is in from of the PCB, and external is in the back of the PCB), and define same macros but with slightly different logics.

AIR_CIRCULATION_INTERNAL: same logic but of course without SERVO
AIR_CIRCULATION_EXTERNAL: turn on external_fan (or put speed in 0.8 like AD5M pro macro), turn off internal_fan
AIR_CIRCULATION_STOP: turn off both fans

The only issue with external circulation is that there is no other fan pulling fresh air from outside, but in theory when used (for PLA or PETG) it will pick the air from the upper side of the AD5X printer enclosure. Thinking in high voice, the AD5M PRO doesn't have any place to pick fresh air and that's why it needs the servo and internal_fan to pull fresh air from outside, but AD5X enclosure is "more open" so can pick air by simple air dynamics (external fan will produce a vacuum inside the chamber, and then fresh air will become inside the chamber by any opening). For example, the the window for IFS filament tubes is more than enough.

I will print a closure for that IFS hole, easy to put/remove, so it can be closed when using circulation internal for materials like ABS/ASA/Nylon/etc.

Finally, call the AIR_CIRCULATION_XXX macros in GCODE in before/after print events configuring the correct air circulation based in the filament.

That's why I think the nomenclature is correct, but for some reason the GPIO pins are inverted in CFG macros for AD5X, I bet some engineer put it like that in early stages inverted and later they decided to don't include air circulation systems and it has been left as-is.