Hear me out for a sec...

[Eniaro]

I was looking for a way to use a 3d printer to do automated testing, essentially a poor man Flying Probe Machine. -No I'm not lazy I have a lot to do with little time-
I came across this little project

https://hackaday.io/project/192272-circuitscout

CircuitScout is a DIY probe system designed to simplify the process of testing PCBs, by automatically probing desired signals. Through an intuitive web-based GUI, users can upload their KiCad files and have the system automatically navigate and probe their PCBs. With the help of CircuitScout, all you need to do are selecting signals from the schematic and checking the output.

Is anyone interested in forking the project?

 

[SolderFungus]

I had the exact same conversation with my engineer friend some time ago. It would be amazing if somehow a mobo could be put in a jig and run/probe with boardview data. I offered my 3D printer for the project, but I doubt we will ever get anything done past the dreaming stage

 

[Eniaro]

In past manufacturing chapter of my life I operated 2 machine a flying probe machine and a Automated optical inspection (AOI) machine.

The AOI simply compares board components to a known good a board then calls out anomalies. This might be a little less complicated to build but would be a solid tool to have

Now the flying probe machine... The most important part is that it needs coordinates: x y z and reference points. If we select the reference points at the beginning of the tests no matter how the board is placed it can be tested.

We have tons of data to pull from I don't think it has to be a dream maybe train ai models on schematics and other data so we can have suggestions of where to look for problems. >>>EMPHASIS ON SUGGESTIONS<<<

Combine both all 3 in one would speed up troubleshooting

I'm going to attempt it to be honest. My skills & funding will probably make it a slow process but if anyone is interested we could have multiple builds going at the same time or working on different aspects I think we could build a solid tool

 

[SolderFungus]

I'm definitively not the guy for writing the code for a project. I have some basic Arduino projects under my belt, however this is going to require something far more advanced to create. It just happens that the engineer's brother is a really talented programmer, and we all thought it would be fun to try, although none of us was sober during that conversation. I'm amazed that I'm reading such a similar thread now and am all for it!

I wonder if G-Code with timed interrupts for measurements is a way to start prototyping with existing 3D printers. I have a Creality Ender 6 that I dont mind experimenting on.

 

[Eniaro]

G-Code would be the way to go and has been proven in the Hackaday project
I don't know much about Core-XY printers, my understanding is that the bed moves up and down while the head moves back and forth left and right
If this is true, the print head will be replaced with a motor to retract and extend the probe. Reducing the need to move the bed, which can board to shift out of alignment

I have a Delta-style 3d Printer the bed does not move but having a retractable probe would probably speed things up.

For the second probe... it seems we test everything to the ground anyway... a gator clip would work for most other cases, and wire and tape

You're right a jig to hold boards in place may also help.

Plugged this into Gemini but haven't validated it figured I'd leave it here for an open review:

Okay, that clarifies your setup! It sounds like you're building a custom automated testing system using a modified 3D printer for precise probe positioning. Here's how you can integrate the multimeter readings into your OctoPrint/Klipper/Marlin workflow:

1. Connect the Multimeter

• Serial Communication: The most reliable way to get readings into your system is to use a multimeter with a serial output (RS-232, USB-serial). Connect this to a serial port on your Raspberry Pi (where OctoPrint is running).
• Analog Output: If your multimeter has an analog voltage output, you might be able to connect it to an analog-to-digital converter (ADC) connected to the Raspberry Pi.

2. Klipper Macro (Recommended for Klipper)

• Klipper allows you to create custom macros with Python scripting. This is ideal for your use case. Here's a basic example:

Python

[gcode_macro READ_MULTIMETER]
gcode:
# Read the multimeter value (replace with your actual reading method)
{% set reading = read_serial_port('/dev/ttyUSB0') %}

# Do something with the reading
{action_if_reading_above_threshold(reading)}

• You'll need to write a Python function (read_serial_port) to read from the serial port and parse the multimeter's output.
• action_if_reading_above_threshold would be another macro or G-code commands to execute based on the multimeter reading.

3. Marlin (More Challenging)

• Marlin has limited scripting capabilities. You might need to modify the firmware to:
  • Read the multimeter data (via serial or ADC).
  • Implement custom G-code commands to trigger readings and conditional actions.

4. OctoPrint (The Orchestrator)

• G-code Scripts: Create G-code files with placeholders for probe coordinates.
• OctoPrint Plugins: Use the "G-code system commands" plugin to execute shell commands or Python scripts from your G-code files.
• Python Script:Write a Python script that:
  1. Reads the G-code file.
  2. Sends G-code to move the probe.
  3. Calls the Klipper macro or Marlin command to read the multimeter.
  4. Based on the reading, either continue to the next test point or perform some other action.
  5. Repeat for all test points.

Example Workflow (with Klipper Macro)

1. G-code File:
   G-Code
   
   G0 X10 Y20 Z5 ; Move to the first test point
   READ_MULTIMETER ; Call the macro to take a reading
   G0 X30 Y15 Z5 ; Move to the next test point
   READ_MULTIMETER
   ; ... and so on
   
   
2. OctoPrint: Upload the G-code file and start the print. OctoPrint will send the commands to Klipper, which will execute the READ_MULTIMETER macro at each test point.

Key Considerations:

• Error Handling: Implement error handling in your scripts to deal with situations like failed readings or probe misalignment.
• Synchronization: Make sure your script waits for the multimeter reading before moving to the next point.
• Documentation: Clearly document your G-code scripts, macros, and any firmware modifications for future reference.

This approach provides a flexible and powerful way to control your flying probe machine. You can easily add more complex logic and decision-making based on the multimeter readings. Let me know if you have more questions or want to delve deeper into any specific aspect!