Better approaches to Probing

[scottcun]

While I’ve only had my V-One for just over a week, I’ve noticed some growing pains with the Probing step prior to printing, when using boards with drill holes. After reading another post related to probing I decided to post as a new feature request around the software for probing:

First, probing should follow the principle of ‘failing fast’: since the wizard will NOT let you proceed with printing if adjacent probe points exceed the ‘Maximum height difference’ of the Beta Setting 'Probing Error Detection. By ‘failing fast’, I’m suggesting the algorithm should:

1. Prioritize probing points more likely to ‘fail’, specifically points around drill holes and/or on the extremes of the X and Y
2. Stop probing and report the error when condition is detected, instead of completing the full pass just to tell the user that probing has failed

The above would at least reduce the failure/fix cycle, though it still leaves the user in a failed state.

Second suggestion would be to attempt to compensate for slight alignment issues by performing additional adjacent probes when a height failure is detected. In another post, it was mentioned that the alignment step takes two samples, the first to anchor the layout and the second to determine its rotation. Since hole sizes and human judgement in alignment are far from perfect, the software could compensate by either:

• Taking additional alignment samples, especially around a known drill hole, to compensate for human error
• During probing, if an unexpected depth gets probed ‘near’ a hole, add additional probe points around the hold to identify the discrepancy, compensate for the alignment error, and adjust the heatmap layout accordingly

The second suggestion is a larger software investment (particularly the second bullet), since I suspect that the alignment and probing routines are independent blocks of code. I think the first bullet would not take as much to fix, and it would go along way in addressing the inherent error variable introduced by the human alignment step.

The second bullet of the second suggestion would probably require a rewrite, since it would basically integrate alignment and probing as one operation.

Of all the steps I’ve taken with the V-One, the Alignment + Probing has been the only one that has been slow and frustrating, especially when you only need to reprint a single trace after testing a baked board.

One other note regarding the Alignment / Probe workflow: I’ve had several (almost 6?) occasions where the probe contacts accidentally disconnect in some cases stopping the workflow. While there’s no simple solution to this from the hardware perspective, the software could at least provide a ‘recovery’ option to raise the Z axis, home, re-mount the probe, and resume where it last errored (and perhaps try to re-probe around the area as suggested above to compensate for human error).

[MikeL]

Thanks for the detailed info, always super helpful to get as much info as possible.

So out of the gate we actually do prioritize the most likely to fail parts of the board. We’ll hit the highest priority stuff before moving on. Last I checked we do holes first, then the hull (or perimeter) of the board and then move on to other features. Here’s a sweet gif showing the order in which we do the Punk Console board, note how much longer the holes take than any of the other points.

While failing the moment we detect any discrepancy would get you to a fail state faster it may not actually get you to a resolution faster. An important part of doing all the probing for a heightmap is getting all the data so it can be compared. If we don’t have all the data to make a comparison it’s likely the solution won’t be clear. This then leads to users making corrections they perceive to be correct only to find there are more things to correct after the fact. Overall this would lengthen the time to getting to print which is rough.

As for the second point we actually already measure a whole bunch more points than we need for things like holes. Any time a hole is going to be measured we’ll hit a way more points than we actually need around the perimeter. We then throw out points we deem problematic and their values are ignored. So the machine should be able to fall into a hole during that without having any negative impact on the heightmap. Of course if the majority of points fall in the hole there will be a problem, though that should only happen if the hole in the board doesn’t match the size of the hole in the drill file.

Just as an example I caused a failure for one of the holes in the Punk Console board. You can see here for the default settings with a hole of that size we actually take 6 sample.

It’s not super obvious in the software but you can see that when holes are to be probed they have a slightly thicker line and no center dot.

You can see what you probing pattern will be by running SHOWPROBINGTARGETS in the console

In terms of the probe disconnect, we’ve had a few reports of that and are currently investigating what could be causing it.

All that said I’ll be sure the software team gets this information, they’re always appreciative of suggestions and ideas for alternate approaches to problems.

Additionally if you’re able to provide some more info on the specific error your seeing that’s always good. Of course the best way to get to me is through our in-app chat which all comes straight to me.

[scottcun]

Hey Mike, thanks for the reply. I spent the last couple weeks over the holiday doing lots of V-One boards, both single-sided on FR4 and double-sided on FR1. I figured out that doing the following 3 things seems to have vastly improve probing reliability:

1. Changed ‘Probing Error Detection’ to 0.20mm (from default 0.08mm) - this value seems to be more forgiving, especially when probing for soldering.

2. Better utilizing the ‘Raise’ and ‘Lower’ functions during board alignment. Previously, I normally would not use the ‘Raise’ button unless the initial ‘Lower’ dropped into a hole, and would just ‘measure’ once I had eyeballed it. Instead of going to ‘measure’, I would perform a ‘Raise’ immediately followed by a ‘Lower’ command to see if alignment was near perfect or off a bit. If I needed to move X or Y for any reason, I would repeat the ‘raise/lower’ procedure until the probe appeared to nail the mark (particularly when probing holes for alignment).

3. For double-sided board workflows on FR1 boards, my PCB designs now include unconnected vias in one or both sets of opposing corners on the boards to provide the greatest diagonal distance for board alignment.

With the above, I’ve had perfect or near perfect probing results.

Based on your reply and what I learned over the holiday period, I’d like to revise my feedback on ‘better approaches to probing’:

1). I understand that getting all of the data may be more helpful in troubleshooting, so let me suggest that instead of lighting up all of the probe points ‘blue’ during probing, and only reporting errors at the end of the probing session, if a height delta greater than the ‘Probing Error Detection’ setting is discovered during probing, the UX should report those points in a different color (and report height delta line segments), so on longer probing runs, the user can decide whether to cancel the probing-in-progress or let it finish.

2). Keyboard shortcuts for the ‘raise’, ‘lower’, ‘measure’, and ‘move to next feature’ in addition to the arrow keys already supported that can be accessed by feel would allow the user to focus their eyes on the V-One probe and not the keyboard and screen. Suggested choices:

• Lower: [Page down]
• Raise: [Page up]
• Measure & Move to Next feature: [Enter] key
• Go to previous step: [Back button]
  Above should also work on the 10-key pad with [Num lock] off

3). My previous suggestion for recovering from probe disconnect still stands