Worthy of note is that bCNC now supports camera alignment for two sided PCB boards. You just need a spindle mounted camera, and then you simply show bCNC a couple of points (by centering the camera cross-hairs on them) around which to do the alignment for the opposite side. This replaces the need to use physical alignment pins to align the two sides, as flatcam does. I haven't yet tried it, but it sounds like a very nice convenience. The "Ant PCB Maker" project has been leveraging this feature of bCNC for one or two years now. I don't believe the existence of bCNC's camera alignment capability is widely known, though, as I only just recently heard about it, and even then only by chance.
Thinking about it now, two known points are required when nothing is pinned because that's how many points are needed to re-establish the origin as well as correct for any rotation that may have occurred after the board is flipped over. So, presumably, first a new origin needs to be established, and then all of the g-code for the second side needs to be amended after-the-fact to account for any rotation that may have happened when the board was flipped.
@BearWithBeard Wow, thanks for this detailed answer!
Today, I received an answer from Ebyte:
Yes, because of the shortage of chips, E01-ML01D is temporarily out of stock. It will be available in next mouth, if you have a purchase plan, please book as soon as possible.
@skywatch So, there is hope
HI All.
Still having problems and this is my first purchase from PCBway not sure if the code need to be changed for this board but I am using PCB MySensors Gateway Ethernet 3.0 developed by fifisoft57. The radios work on other projects and it is almost like the pins are not correct I traced them and they appear right but......... Has anyone used this board if so did you have any issues? I would say it is my solder job but I did 3 boards one should work.
ANy help would be great.
@BearWithBeard said in Report in Imperial Units:
...
I feel like I gave you the same answer as above, just differently worded.
Still, I hope this makes it a little bit clearer for you.
Thank you very much for this. What you did in this one is flat out state that MySensors is unit agnostic and does no conversion, etc. The existence of getControllerConfig().isMetric made me think there was more than a setting which said "This network is in a imperial/metric location." Probably because I am not used to coding or examples for both via a setting, but typically see "comment out ___ and uncomment ___ for ___ units." I now understand that this was my error and do agree that the setting is a better solution than I am familiar with. So while you may feel you stated the same, what was missing for me was a that the sensor library was used to control reporting units and not MySensors. Makes sense to me as I was wondering how mixed units might be handled.
Again, thank you very much for explaining this.
Kindest Regards,
Karl S
@vecnar Nice job! I think that I too will mostly stick with my current smoke alarm setup until either prices on the Nest drop to parity levels or something better comes along. Kinda the "if it isn't broken, don't fix it" philosophy. If it turns out that de-dusting my smoke alarms on a regular basis provides 100% anti-false alarm protection, then I may never feel the need to upgrade at all. Meanwhile, I think I will replace my ionizing smoke alarms with photoelectric ones, since photoelectric smokes alarms are thought to have many fewer false alarms.
