I’m creating a post to document my switch as reference for my future self and for others in case they also go this route.
Things I’m looking for the migration:
Progress for headless setup:
Great thread to start!
For RapidChange support, to my knowledge so far this is roughly where they’re at since I last spoke with their team - though into the future we’re hoping to make it so gSender doesn’t pause during tool change (optional) as well as integrate it more deeply into firmware
I’m still waiting for my SLB to arrive. I wish I could get the SLB-Ex that you used for the AltMill or maybe an SLB that’s 36V capable.
In the meantime, I forked the gSender code and was looking through it. It looks like a simple change to add a conditional statement and a configurable option to disable tool confirmation.
Once I get my machine running, I’ll focus on the software side and maybe submit a pull request to your base code. I’m actually working closely with Don. He gave me a good offer on the ATC, and I’ve been helping him in my free time.
I’m also kind of interested in starting to learn grblHAL. It seems like it would be better to implement this there instead of the more limited GRBL gcode. I told him, based on his video, there might be a better way to handle tool changes without uploading a gcode file.
I saw your repo for it: GitHub - Sienci-Labs/sienciHAL: Fork of grblHAL to make our own SLB firmware
I’m a software engineer by profession but still need to learn the programming language for this.
I know you guys are pretty swamp with all this development so I will just do whatever I can do to help. 
. I really like what you guys are doing on both the hardware and software side.
Here’s by the way the AutoDustBoot I created so it can work with RapidChange ATC cause I hate cleaning mess.
Ah cool I’ve seen this! I shared it around the office since I thought it was pretty slick. By all means if you’ve got a background in this stuff feel free to contribute - it seems like we’re always slammed and ultimately are doing this to help further the community to so any contributions are welcomed
Adding hall-effect limit sensors. Stall homing will no longer working and it’s not that accurate anyway which is really needed for the ATC repeatability.
Here’s the 3D mount I created:
And the hall-effect limit switches:
https://www.amazon.com/dp/B01MZYYCLH?ref=ppx_yo2ov_dt_b_fed_asin_title
Not good start for me. Already doing troubleshooting for my spindle.
I think the SLB is not getting the speed or the VFD is not sending it and then the firmware trigger spindle timeout.
Good to know it’s on the firmware side and not sender side 
Perhaps since you’re only getting the alarm after frequent changes then you might want to look at Firmware settings $392 and $340? I’m not the most familiar with spindles, there are other on our team who are better versed and can answer via ticket on our contact page, but I think it’d be worthwhile to give it a shot.
My logic is if you’re not getting the error right away, then some sort of communication must be happening. One other pro tip, in gSender console if you hit the up arrow on your keyboard you can bring back older sent commands which can save time when reusing them instead of retyping
Hope to hear more progress, good luck @siganberg!
It’s currently set to 0, which should be disabled. I think the problem is the SLB is not getting the data or not able to parse the data coming from the RS485.
I also tried increasing it the $392, but had no luck. I have already created a ticket for this issue.
Here’s another video that leads me to believe it’s an issue with the SLB board or the firmware loaded onto it. I tried reflashing it again, but I’m still getting the same error. In this video, the board totally hangs freezes even after hitting the e-stop. The only way to proceed is to power cycle the SLB.
So, there’s good news and bad news. I bought another VFD to rule out any issues with my original one.
After installing and configuring the new VFD, I’m still experiencing board freezes. To make matters worse, my MacBook froze twice as well, leading me to believe there might be a problem with the USB connection from the SLB causing my MacBook to hang too.
What I did was disconnect the USB connection and connect my SLB directly to my network. I assigned an IP address within my subnet and configured gSender on my MacBook to connect to that IP. To my surprise, it’s working—no Alarm 14, no board hangs. I executed a few M3/M4/M5 commands, and everything on the spindle UI worked without any hiccups.
I decided to reconnect my old VFD, and it still throws random ALARM 14 messages, but the SLB never freezes; it can recover simply by clicking the unlock button or sending the $X command.
After all this troubleshooting, it seems the SLB might be defective at the hardware level, as it’s causing issues with the USB that even affect my MacBook.
@chrismakesstuff, I’m also a bit disappointed with the technical support. It seems they only respond once a day in the morning, even though I’ve replied and provided more details about the problem, including a video that clearly shows the issue. According to the Sienci site, calling is more limited than submitting an online ticket, which makes it feel like both options are lacking. I understand you’re likely swamped with all the new product releases and have limited staff, but after-sales support is really important.
I’m not sure what the next step should be after all this troubleshooting. Should I file a warranty claim? I still need a reliable USB connection, as not every G-code sender supports a network connection to the board.
@siganberg I’m seeing your stuff. I’ve done some checks on my end and can’t replicate the issue but importantly I don’t have your VFD or Mac setup so perhaps there’s something there I’m not getting.
When you say this VFD was working on your Onefinity, were you using RS485, 0-10V, or 5V PWM? Another option could be to try to replicate the setup that was working for you before since the SLB can also support 5V PWM. Otherwise, I think it would make sense to send you a replacement to see if that resolves the issue since I understand your point on having a USB connection.
One piece of good news is that the other day I was speaking to the main developer of UGS and we wound up sponsoring him an SLB since he was interested in further improving UGSs compatibility with grblHAL - so hopefully it least UGS will introduce more functionality in the coming months
I’m trying to speak with others on our team in case there’s something else we can think of. If you’d like to send a replacement I can hop on your ticket and facilitate that
@chrismakesstuff Thanks for getting back on me about this. Really appreciate it. Last thing I want is to bother you.
In Onefinity, I’m also using RS485, prefer using less wiring and 2 way communication. In disperation, I was gonna try the PWM and just realize Huangyang PWM is 10v and I don’t have a converter with me.
For now I’m gonna continue wiring my CNC, I’m just worried if this unit has really leaky voltage spike or some noise that affect the realiability of the operation, since I haven’t even connect all the steppers, limit switches, etc… One of reason I pick the SLB is the noice isolation of I/Os. I have that headache on my first CNC (shapeoko v1). A replacement would be nice so I can swap it later. Was actually though getting the SLB-Ex because I really wanted a 36v system but I don’t have yet all the close steppers available.
That’s really good news. More options for other to use different gcode sender for the SLB.
@siganberg, just spent all day with the team testing spindles and plan to continue with it tomorrow. Turns out the old batch of spindles we ordered and distributed performed well but the new batch the majority are having Alarm 14 errors too. Now Alarm 14 is generic, so it’s hard to say what the origin is in each distinct case, but it’s causing us to spend time trying to diagnose whether there’s any improvements we could be making to the SLB firmware or if the units are plainly defective.
One interesting thing is that for many of these units when you run a job with the spindle on, it seems you can override the spindle speed as much as you want during the job without an alarm appearing, but if you perform manual control and continue changing speeds sometimes it sets off the Alarm (if you’d like you could try this yourself and let me know what you see). Hope to find results one way or another but we’ll see where it comes out. It might also be a VFD setting that’s not giving the SLB enough time to communicate with it or sending a response back to the SLB quick enough. These are both quite complex systems, I just spent 5ish hours going through hundreds of settings and will have to review them over many times more until I can see what might be going wrong.
As I mentioned, if you’re feeling at all uncomfortable about your board we could still process a return for it. Whether you’d like to or not, I’ll be aiming to get to the bottom of this best I can alongside others on our team since it’s always good to know where problems come from
Another thing I thought I’d mention, most VFDs actually typically have a setting that allows you the adjust the incoming voltage range from 10 to 5V. This could technically allow you to try it out without a converter. For the H100 I believe the setting is F070 when you hook it up to Analog Input 1
I feel your pain—I’ve been doing that for two days. 
There’s a good chance that my other VFD is bad since the new one is working flawlessly right now, so I’ll just stick with it and move on. I’ve started working on other things, like tuning all my stepper motors to my machine. It’s been a while since I worked with GRBL settings, and I forgot how complex they can be with all the customization.
I’m now working with my ATC and found an already-written plugin for RapidChange ATC. I’m just experimenting with it by compiling my own SienciHal firmware with this plugin. I was able to flash it, but it still needs more tweaking to make it work.
Here’s some productive progress for me today:
Wow, no way eh?! That’s been on my bucket list for a hot minute, that’s looking great!
I was talking with the author of the plugin, and he already suggested moving to the macros using SD card approach, as it’s easier to customize. However, it’s not as sleek as the plugin. I might try that macro first since I’m not really proficient in writing C++, though I am a C# veteran.
New ground broken today as far as results for our own internal units!
It appears that as far as grblHAL’s pre-built spindle libraries are concerned (though this might now be fixed in the main ‘core’ but we haven’t pushed upstream to rejoin yet), there seems to be some additional retry features or error checking built into MODVFD that the other ones don’t have. This was confirmed after decoding the values needed for $462 through $471 for the H-100, once spindle control of the H-100 was happening through MODVFD the operation smoothed right out, and we could switch back to the H-100 profile and experience Alarm 14s all over again. The other aspect we found was setting $340 to 100% which also seemed to occasionally help though more testing should be done to further confirm.
Plan now is to try to investigate where the source of the error correction is coming from, and see if it’d be possible to implement across all other profiles (or if they’ve already been implemented upstream) then introduce them in a new firmware build to distribute. @siganberg I’d be really interested to hear if this resolves your issue too since that would increase my confidence in this being the source. We’ve seen other reports of this happening with other grblHAL boards too and other VFDs accross different communities, so if this is all ties together then this could be a big solve.
Otherwise, gonna go relax for the Thanksgiving long weekend now, take care Francis!
