Has anyone looked at this new Controller?

I’ve finally started moving on getting my SLB working, and I’m experiencing similar behavior. Lots of variables since I hadn’t completely dialed in alignment, but I was able to jog Y forwards/backwards in 5mm steps without any problem, but any rapid movement immediately stalled the Y motors. I dropped my acceleration down to 300 and this ‘seems’ to work - I’m able to rapid now - but I only got to this point late yesterday and so much more testing is needed. I’m hoping to spend some more time on it today. (I didn’t change my speed settings, but my rapids are short enough and accel low enough that I’m not getting anywhere close to max speed anyway)

I will add though that I originally had my machine set up with an XPro V5 controller, and while it was somewhat less fragile than the SLB, I also ran into Y stalling problems. So, this doesn’t seem to be unique to the SLB (but, the XPro is also a 24V machine)

There is another thread going here: X-Axis Stalling on Y1 Rail getting misaligned where tKC was experiencing Y stalling problems with his Pro machine even with the BB-based controller. The diagnosis there appears to be that some Pro machines shipped with incorrect motors, and I have the same model motors on my machine. Whether this is a real problem or not remains to be seen.

I also had Y axis synch issues with the BB, so it has to do with an imbalance between the motors at high speed. Higher speed = higher voltage and amperage. Possible it’s due to the different Cable lengths. The X axis runs at Max speed and Accel just fine. I did learn that Max rate is limited by the ballscrew not the motor from a 1F tech rep (X/Y 393 ipm Z 118 ipm).
Anyway, I have my X Max rate at 9982 mm/min Max Accel 1000 mm/sec^2 (gSender Firmware #110 & 120).
Y is Set to Max Rate 7620 mm/min and 450 mm/sec^2 (#111 & 110). And so far it’s running and cutting great.
Also, depending on how you adapted your cable for plugging into the SLB is very important. Check the 1F connectors to be sure the pins are even, I found 1 of mine pushed in. Solid connections are very important. I tried using the Molex connector 1F uses to keep it stock, but even after getting a crimping tool I just couldn’t keep all the pins from pushing out. So I switched to using 4 pin aviation connectors. (my career was aircraft maintenance).
I hope this helps,

Of course, if you can afford the Elite upgrade of $2100 you’ll have a primo machine. But compared to $165 plus a 24v power supply $50, and setting up limit switches (make sure to get 5v) (which I did using the BB, just didn’t like it’s bump limit) another $50, so $265 to get all the CNC functionality. The only con is that it’s not a stand alone controller (which was one of my checklists when I was upgrading), but I still needed my computer anyway.
I do know that Scienci is working on making a tablet dedicated to the SLB which will make it stand alone. They’re trying to do this for under $500.

Bruce
Fallen Branch Woodcraft
Owensboro, KY

2 Likes

Hey Bruce,

regarding the speed with which electrons move through copper (=electricity), it is highly unlikely that this length makes a difference. A cable of the length of the Atlantic Ocean’s width would, though.

If I had such problems I would first check and ensure that your machine is

  1. rectangular (“squared”) (bar gauge) and 2. coplanar (“not twisted”) (fishing line method)?

If rectangularity and coplanarity are not perfect, the Y movement can block or have “hiccups” or loose its position reference coordinates.

Next thing I would check is all points one by one in this document:

I would also consider:

By the way, you’re answering off-topic on an off-topic post from @dwkdnvr.

Keep It Tidy

Make the effort to put things in the right place, so that we can spend more time discussing and less cleaning up. So:

  • Don’t start a topic in the wrong category.
  • Don’t cross-post the same thing in multiple topics.
  • Don’t post no-content replies.
  • Don’t divert a topic by changing it midstream.
  • Don’t sign your posts — every post has your profile information attached to it.

Rather than posting “+1” or “Agreed”, use the Like button. Rather than taking an existing topic in a radically different direction, use Reply as a Linked Topic.

– Source: This discourse.org Forum’s FAQ

1 Like

This right here. I’m moving toward a pure LinuxCNC setup. I’m replacing the steppers at the same time so I won’t have to cut or mangle anything factory from 1F. I’m trying out one of the small LPT breakout boards. I’m also adding limit switches.

1 Like

My 1F controller just broke again while working on my AutoDustBoot. The M8 port stopped working, and RS485 failed too, so I can no longer control my spindle. I can still manually start/stop and control the spindle speed through the VFD, but now it’s basically functioning like a simple router, which is useless with my RapidChange ATC.

Given my current situation, I’ve decided to move on from the 1F controller. In my opinion, it’s too basic and has a lot of quirks and bugs (e.g., it doesn’t recognize G53 in the UI, and the UI halts when it encounters invalid range g-code, requiring a complete reset). Plus, it’s overpriced for what it offers ($500). So, I’ve ordered an SLB, and I’m waiting for it to arrive.

In the meantime, I started exploring the software. I was able to set it up on my spare Raspberry Pi 4 and did a headless setup, which was one of my requirements for switching to a new controller. I configured it to launch on Pi startup and set up the web server for remote control so I can upload files from my desktop and control it from my tablet, staying wireless.

From this short test, I can say that gSender is far more polished than Buildbotics or Onefinity’s UI. I’ll probably make a tutorial video later once everything is set up.

Hey Francis,

you probably mean that G53 fails silently if G53 is used while G91 is active. However the g-code standard defines no standard behaviour for this case. It simply implies that you never use G53 while G91 is active. It would be good style if a CNC controller emits an error if G53 is used while G91 is active, which the Buildbotics/Onefinity doesn’t.

Anyway I believe that the forum users will appreciate your experience with the alternative controller.

Considering that the Onefinity and the Buildbotics contain much more than the CNC Controller, but also the four stepper drivers and a power supply, I always found that it is not expensive. The Onefinity CNC Controller when sold as a bundle is much cheaper than $500 (subtract the “black box option” when ordering an Original or PRO Series, and you see the real price difference).

I’m not using it with G91 (I’m not sure if G53 and G91 together really make sense). I’m using it with G90. The issue is that the UI doesn’t recognize it properly and renders it as outside the machine’s range. The UI also claims that X, Y, or Z might be invalid (either under or over the machine limits), but that’s not the case because you can still run the program and it works fine. I’ve already created an issue on GitHub: G53 doesn't recognized by the UI · Issue #91 · OneFinityCNC/onefinity-firmware · GitHub.

Another annoying issue is that if you have invalid range g-code, the system halts, and the only options are to perform an e-stop or a complete power cycle. This causes you to lose both your machine coordinates (which keep changing because stall homing isn’t very accurate—I’ve tested this with my RapidChange Tool, where it sometimes grinds) and your offset coordinates.

36V Meanwell power supply isn’t that expensive. The SLB also has built-in drivers and case, Plus, it only costs $180. I also considered FluidNC, which is under $60, and getting four closed-loop steppers like the MKS SERVO57D, which would still probably be under $200. However, I chose the SLB because it’s more refined and made by the same people who developed gSender, which, in my opinion, is a very polished g-code sender compared to everything else I’ve tried. It also has grblHal and very active development.

Hey Francis,

I try to reproduce your error, however no limits error appears. Here is what I tried:

G53 G90 G0 Z0
G53 G90 G0 X610 Y408 ; I go to somewhere in the middle of the machine - journeyman
G92 X0 Y0 ; I set an offset here

(debug, Now I home the machine)

G53 G0 G90 Z0 ; I reproduce your position in machine coordinates
G53 G0 G90 X0 Y810 ; I reproduce your position in machine coordinates

(debug, Now I load small_program_journeyman.nc)

; this is small_program_journeyman:

G53 G0 X1220 Y816

(debug, now I execute it – no limits error)

So I don’t exactly understand in what the error you mean consists. I did not find that the subsequent movements referring to G53 (move in machine coordinates) based on the offset. They were obviously based on the machine zero, which is what you expect. Maybe you tell me more exactly what error you see.

this indeed is something that I always found strange on this controller. Why should we loose our positions on an error or if we estop?

One of the reasons why I don’t plan to use the buildbotics/Onefinity controller on my machine.

1 Like

The M8 port? You mean Load-2? does it not switch anymore? What did it control?

And are you sure that it’s the RS485 port on the controller? Usually it’s the cheap VFDs which have this port failing. The controller has a reliable interface chip there (and it’s the only signal line that is not directly wired to the AVR microcontroller)

Yes, I’m pretty sure. I tested both the breakout connection, which should return 3.3V, and L2, which should return Vcc (36v). M7 is still working as expected—it was controlling a relay to turn off/on my vacuum and the AutoDustBoot I recently created (here: https://www.youtube.com/watch?v=5ENXbViEY54).

I even tried replacing the ATXMEGA192A3U chip, but I can’t seem to flash it with the firmware. This is the chip responsible for all the I/O including RS485 ModBus. I soldered the old one back in. It’s more likely the 1F than the VFD (I hope so). Both went down at the same time—when I was testing, I heard a power cycle, and after that, M8 and the spindle stopped working.

I wish I could send screenshot of the bugs, but at this point, I’m so tired of dealing with the 1F that I gave up and don’t want to reinstall it.

I’m a pretty advance user and do a lot of thinkering. I can’t afford $500 every time I screw up something with my experiment. :slight_smile: . At least with SLB or other controller, I can buy it separately without PSU or againg Pi 3. For other users 1F controller make sense.

I just meant because the RS-485 port is no direct connection to the AVR chip but has the ISL83485 Transceiver chip (and a commons mode chocke) in front of it.

Onefinity_RS485_port
Image: Onefinity Rev. 5 CNC Controller – Circuit Diagram (excerpt)

The AVR is programmed onboard but if you use a brand new chip, you got to program the fuse modes first

But I understand you. Even if one deeply can admire what the buildbotics author achieved first with writing camotics.org G-code simulator and then creating the buildbotics.com CNC controller, I see some problems in the fact that the *nix and the open source worlds are not his primary backgrounds and I see problems in the fact that he wasn’t able to pack buildbotics firmware as a regular and proper dpkg package, which would allow to downgrade or purge the package instead of this constant stupid reflashing of the SD card just because they have no clue of *nix and De[bv][iu]an packaging systems and are not able to purge a package with a single apt command. And first of all, I don’t see why would I use the buildbotics or its Onefinity derivate, when LinuxCNC already exists. The only reason to not use LinuxCNC is if you don’t know how to choose and build you own PC hardware. LinuxCNC is so evolved nowadays, I doubt anything can compare to it, and it’s free and open source software.

1 Like

by the way, are you aware of these possible causes for port issues:

I’ll give it one more try. I think I have ISP programmer on my stash. What else I can do anyway while waiting for my SLB. :smiley:

I will also check the connectivity of the DB25 pins to the PCB. You might be right cause the cable I use from my prototype AutoDustBoot was tangled during the x-gantry move because I haven’t put it inside drag chain. So might be likely that it pull some solder pins. But not sure about LOAD-2, even the LOAD-2 port on the back on the controller is not triggering the Vcc.

1 Like

Well, after more troubleshooting, LOAD-2 is definitely not working. I can’t get it to go HIGH and measure directly from PIN 31 on the chip. I also traced the RS485 connection, and it’s good, but it still doesn’t work. Unfortunately, I don’t have the right equipment to measure serial data on these two lines.

As for the SPI port, I can’t find any pin on the schematic for Rev 4. I do see PDI pins on J4. I found a Buildbotics repo for programming the AVR through a Pi and PDI pins here: https://github.com/buildbotics/rpipdi. But now I need to get the PDI interface as opposed to the SPI, if that’s correct.