Hi all - This is probably a naïve question, but does the openbuilds blackbox x32 support two 6-36v per axis (when wired in something like series?) These are the ones I purchased: M12 Inductive Proximity Sensor LJ12A3-4-Z/AX Normally Close Detection Approach Switch NPN NC 3 Wire DC 6V-36V I wired one axis as a test up in parallel, but they didn't work as expected - so I re-wired them in series, and they did work for that axis, but since doing so, I found some responses on this board that dual proximity sensors aren't supported, so before I go further with any other switch wiring I wanted to double check. I didn't see anything in the docs. I am also contemplating just swapping in mechanical switches instead, but have read they are more inaccurate which leaves me in analysis paralysis to some degree. I guess the third middle ground option is to just wire three normally, and then use soft limits - but something about hard limits everywhere makes me feel a bit more safe. Opinions encouraged though - I don't know what I am doing to be honest. Thanks
Inductives themselves don't react well to series/parallel wiring (active devices, does more than just a simple switch) so usually not easy to do without external AND/OR gate circuitry - they interfere with each other. Coupled with the terrible repeatability - I'd recommend grabbing https://openbuildspartstore.com/xtension-limit-switch-kit/ (can parallel super easy, higher precision than inductives, onboard EMI filtering - overall better) and leave the inductives for the only good use case they have (waterproof, specific for machines where thats the main concern and the wiring difficulties and lack of precision are acceptable tradeoffs) Even just as homing (with soft limits) the Inductives aren't great at repeatibility causing issues with jigs, or recovering failed jobs, etc - you want homing runs to end up triggering exactly the same point for repeatability between runs
Ah interesting, OK thank you for confirming - I will go ahead with the mechanical switches as you suggested - Thanks! On a slightly different note - but not to clog up this board with a new thread entirely - I had another question about the x32 blackbox and was wondering if you had an opinion/thoughts. I've noticed each time I want to connect my PC to it via USB, I need to hit the "reset" button on the blackbox, otherwise it will just timeout/fail to connect. After the reset, it connects first try. This seems to always be the case after having everything powered off. Generally, my PC powers on first, and then the blackbox PSU gets power, and the blackbox turns on, meanwhile the cable itself is always connected. I wouldn't think it was any time of order of operations thing, but I guess you never know. I was planning to submit a support ticket, as I didn't find anything in the docs for this either, but was just wondering if you may know, or if I am doing something incorrectly. I appreciate the help greatly.
There is a rewritten comms section in the next CONTROL update (not out yet but very soon) which may help
Ah gotcha - understood, thanks for confirming that also. Is there a way to trigger a reset via an additional button or something I can add external to my electronics box? Power cycling has no effect, assuming because the USB provides some power and probably does more which I won't pretend to understand. Overall this wouldn't be a huge issue, except I was hoping to just have this be hands off in a closed electronics box.
Try a different PC, make sure you have drivers from the BlackBox docs page. Its not typical, more of a PC problem
I appreciate the help - yeah I assume its a driver/PC issue like you said. The drivers on the doc page didn't resolve the unidentified device/port initially so I installed drivers from sillab site directly, which does let me connect via USB (with the mentioned problem of having to reset first) but I also am having other issues that I didn't see yet- ie the controller disconnected/timed out/etc while I was running the hello world g-code so I am going to update windows, and then dig more into it. Thanks for the point in this direction
Definately the older driver then - you should use the newest ones they handle DTR/RTS (autoreset handshake on connection) correctly. Removing old Silabs drivers takes some work via device manager > driver tab - but note the versions of the driver in device manager to keep track of whether you have old ones or V11.3x As there were inductive endstops involved, I guess we can assume its not 100% OpenBuilds kit right? So what else is in the mix? Using our recommended PSU (if not, probably dirty power from PSU), using our Xtensions Limits (if not, others are more susceptible to EMI, we have nice filters on Xtension Limits), Using a router or a chinese VFD (If so, they create a tonne of EMI, see our EMI FAQ in BlackBox Docs but mainly resolve the SOURCE of the EMI)
Yeah - I'll do some checking of the driver versions and see what that does. reading the EMI response though also makes me wonder if it isn't a purely USB issue Yeah your intuition is correct - it is a mix, however the blackbox/PSU are openbuilds, but yes a chinese spindle/vfd. The time that I saw the controller stop responding was when I had the spindle on for the hello world, so EMI or noise in general getting back to the blackbox is also a fairly likely issue. If noise was interfering with the inductive end stops, they would show as tripped/alarmed? if so, I didn't see that manifest, what I had seen was just that the g code seemed to pause, and then no buttons responded in the controller software (ie, the abort button) - so I just hit the e-stop. The only reason I am not 100% sure if it still could be a USB issue - is only because when I saved my steps/mm setting, I noticed similar behavior where the control software seemed to freeze up (with no spindle or anything running/active). Maybe the VFD had power though, I can't recall as that was last night.
Induced in signal wire yes. But Power/GND present in bundle too, EMI induced electrical noise causing ripple on power rails... Other problems VFD the most likely cause, leave it off and run a couple air cuts, you'll see the issues are gone. With right driver first please
Yeah, I think your analysis is right, when I did the hello world with the spindle off, it seemed fine now that I think about it. But - I have only tried a few tests so I guess I hadn't made that correlation. Any documents/resources/things to specifically google or anything to remedy the issue that I should check out? I do have them located quite close in the electronics enclosure, if that has any significance. Once again, I appreciate it greatly.
docs:blackbox-x32:faq-emi [OpenBuilds Documentation] but with VFD specifically, main thing is to "stop the VFD being nasty" rather than "lets protect everything else around it from its badness" - best strategy. Properly earthed, shielded cable between VFD and Spindle, VFD cabling well seperated from low voltage cabling etc
