For others reference, until I have the chance to implement this into our docs, the values used for H-100 were:
Run/Stop (operation) $462 = 512
Set Frequency $463 = 513
Get Frequency $464 = 544
Run CW Command $465 = 2
Run CCW Command $466 = 4
Stop Command $467 = 8
RPM input Multiplier $468 = 10
rest are defaults ($469=60, $470=60, $471=100)
And that came from referencing the manual really closely to find 3 hex values for the first three that needed to be converted to decimal, then three binary values converted to decimal, then the last was trial and error until it seemed to be correct. This is an easy site for value conversion: Binary to Decimal Converter
0200H ā 512, 0201H ā 513, 0220H ā 544, 00000010B ā 2, 00000100B ā 4, 00001000B ā 8
Thatās great! I will definitely try these settings later since I still have my problematic VFD. Thank you very much for looking deeper into this issue and finding a possible solution.
Iām currently working on integrating RapidChange ATC. Unfortunately, the core of SienciHAL and some of its plugins are lagging behind the forked repository as you have mentioned, and I need some of these updates to make the macros workāspecifically, support for RS274 NGC expressions.
I tried pointing the core to the original repository, but I discovered that much of the SienciHAL src code are not compatible with the latest core and some of the plugins too. For now, Iām tracing the missing code just to support RS274 NGC expressions.
Looking at the state of the code right now, I can see that thereās still much work to be done to merge it back into the grblHal core.
Nevermind this, RS274 NGC expressions actually works, I was enabling in on the SLB-Ex board instead of the regular SLB.
Got my first tool change. The only problem is my tool detection sensor of RapidChange is not working so I disabled. The macro will issue M0 (Pause) command without the sensor for manual confirmation but I canāt seems to figure out in gSender how to resume it. I remember the Pause/Stop is only visible in gSender to the viewer when you are running a job but the macro is kinda small job.
I got a chance to put all these settings on the firmware but no luck, still getting ALARM 14 on my other VFD. I think we can rule out that my VFD RS485 is bad on this one.
These are the settings for H-100, so youād have to adjust them for yours. What your model number again, I might be able to find the values for it online
I am currently working on fixing the code for the gSender. The tool change Passthrough is not functioning correctly and alters the M6 command to something like (M6)(Tx), which grblHal doesnāt recognize.
I was able to build another package and test it, and so far, the job with the tool change has been completed successfully.
Dang I guess i wonāt be able to know if the fix that worked on our end wouldāve solved your situation too.
Super cool to hear about the tool change progress youāve been making. Feel free to submit as PR if it seems to have fixed things and weāll integrate after some testing. Weāve been a bit quiet on gS support recently since weāve had out heads down on a rebuild to set up gSender to into the future and the first Edge release is nearly there (thereās a post I said it was nearly there over a month ago but now weāre actually almost there) and once we can put that out then we can go back to doing some more maintenance
I will. Basically, I just modified the behavior of the Tool Change Passthrough flag in the settings.
Currently, gSender alters the gcode when it detects an M6 command regardless of the Passthrough value, converting something like M6T1 into (M6)(T1), which the firmware doesnāt understand and essentially skips. I made it that the Passthrough flag is switched ON, gSender wonāt alter the code and will send it directly to the board.
Iām not sure if this is the best or safest solution, but itās the quickest fix I can think of.
Finally got some time to complete all my goal for switching to the SLB.
Hereās the demo video.
The current SLB firmware occasionally throws parsing errors, likely due to being somewhat outdated compared to grblHal STM32F4xx, which seems to address some of these parsing issues. The current workaround when this error occurs is to perform a manual jog, which allows it to continue working.
This is so SO COOL. Iām working with Terje right now to start bringing SLB firmware back to grblHal STM32F4xx so that should hopefully help out. This is a killer system especially on a hobby budget, really cool attachment system youāve rigged up for the shoe and motor too.
Sounds like the summary of changes made so far are:
gSender tool passthrough fix
grblHAL customer firmware build with RapidChange plugin implemented
For this one, Iām still using the sienciHal stock firmware with the exception of changing the parameter NGC_EXPRESSIONS_ENABLE=1 in the platformio.ini during build. This is necessary to be able to run the needed macros for RapidChangeATC thats in the SD-Card.
I did try to switch to stock STM32F4xx from grblHal but encounter more issue.
By the way, I created a pull-request for my changes for the gSender.
Would this also be possible to do using the Start/stop g-code in gSender? Or are you needing the commands to be sent at a specific time that start/stop canāt accomodate
Thanks for the PR, Iām sure we can pull it through - we might have to find another way to make the dialogs togglable since I think others are using the ācodeā option and want dialogs to not be present for that too - but itās doable either way. Iāll have to check out the NGX expressions flag, since if thatās all thatās needed otherwise then i can note it down to include in the next firmware update. With those changes in it would seem that your setup would be then possible with all stock setup
Note that the Altmill requires/suggests you use a 4" dust collection hose. It would appear to me that you are using something like a 2" hose which likely is insufficient
YMMV
Mine doesnāt need it. Iāve been using just a shop vac since my Shapeoko days. If you watch my video, I even lower my Festool MINI CT (a shop vac) to half power.
I guess it really depends on how much material youāre trying to pull. For an average hobby job, 2" is good enough.
