Here are my config settings. Can you see the invisible characters in your config to compare them to mine?
uart2:
txd_pin: gpio.14
rxd_pin: gpio.13
rts_pin: NO_PIN
cts_pin: NO_PIN
baud: 1000000
mode: 8N1
uart_channel2:
uart_num: 2
report_interval_ms: 75
If you canāt find an error in your config.yaml, time to double check wiring. Did you use one of the FluidDial PCB kits or wire everything up yourself?
Note that Bartās reported a fair number of blown ESP-32 UARTs from ESD- so follow good practices when handling the wiring.
If it isnāt up and running for you, it is probably best t start a new forum topic to troubleshoot your build.
After verifying your wiring perhaps you could post some pics of your wiring- someone may spot something
Well, the fluid dial is on the back burner until I get the machine working properly and work out the current gremlins.
quick question though before I take MakerJimās suggestion and start a new thread.
WIll the fluidnc dial work regardless of the host CAM software?
IE: my preferred CAM software is UGS Platform and not FluidNC webUI.
I presume that since the pendant is directly connected to the Jackpot it will function regardless of the cam software running the mpcnc.
Also I presume that both can operate simultaneously IE: a USB connection to UGS as well as the GPIO connection to the fluid dial.
The jackpot runs FluidNC, I donāt think you can just use another CAM. I canāt quite imagine how thatās going to work.
In the sense of CAM referring to the software used to output your G-code files, there should be a GRBL-flavor option and you should be OK. From the standpoint of being able to jog the machine around and set zeros on each axis and probe for material surface, etc., the pendant is made to control a board that is running FluidNC firmware. To the degree that some other type of controller software is either FluidNC compatible, or at the very least GRBL compatible, you might be able to use it, but I have no idea what your odds are on that.
Yes indeed I had rx(OUT) from jackpot connected to RX(IN) M5 dial and TX (Out) from Jackpot connected to TX(IN) M5 dialā¦
You really do have to hit me on the head a few times with a shovel before it sinks inā¦!
Switchen the RX (Out) and TX (Out) on the Jackpot did the trick.
As Doug pointed out my (verbiage) may not be correct.
Jackpot (running FLuidNC)
Windows PC Running UGS (Universal G-Code Sender)
connect PC to Jackpot via USB and establish a Com Port (COM 3)
Instruct UGS to connect using GRBL on Com 3 to a CNC control board
Nice little handshake and the G-Code Sender (NOT CAM) is connected to the Jackpot.
I typically use AutoCAD to create vectors then import them into Vectric to define the tooling and export the G-Code with a post-processor then Open the G-Code with UGS and connect to the board and away we go.
CAM- the software that creates the toolpath,doesnāt matter to the operation of the pendant.
Thatās a gcode sender.
The pendant isnāt useful when using a sender.
In fact, using a sender is somewhat irrelevant for the Jackpot.
The preferred workflow is to copy the file onto the SD card and start/run the job from there.
Pendant and WebUI allow you to interact before starting the job.
USB to jackpot works for small lasers and non-flying controllers.
Itās the worst possible way to use a Jackpot on a LR or MPCNC.
You really donāt want a long USB cable from you computer all the way to the jackpot.
Sweet! Good job troubleshooting that.
Com3? Please check the available com ports first
Does your pc support to be a Hotspot? Connect your controller to it and just be sure that sleep/ hibernation is disabled. Thats the more reliable way to connect imo my setup involves a raspberry pi a touchscreen and the v2 webui.
I believe there is a fluidnc controller app in the Google Playstore but it have ads the free version.
Yes UGS is a g-code sender which every way you cut it something needs to feed the g-code to the jackpot I just prefer UGS because thatās what Iāve been using on a Shapeoko for years now.
I disagree that the pendant is not useful when using a g-code sender I can get right up close to the work with the pendant and setup to use the touch probe and establish a work 0,0,0 and jog the machine while looking at it and not the monitor etc. Essentially most of the prep-work Iād do in UGS can be replaced with the pendant and having both gives me options.
My setup might be a bit different than others: See attached.
Iām just not a fan of wirelessly sending data to something controlling a spinning router bit.
Iāve already experienced the FLuidnc wifi glitch and disconnect and then reconnect.
Iāve just never used the SD card route but can imagine that is even better than USB and wifi.
I may give that a go sometime.
I may give the webUI another chance for a small job like cutting out something simple just to confirm itās working.
Unfortunately, I fall into the category of Old Dog and my ability to learn new tricks is limited.
Side Note:
The first REAL thing this robot needs to make is a cover out of plexiglass for the control board housing which will also be where I store the keyboard on top of the plexiglass.
Hopefully whatever you feel comfortable with is doable for you! Bear in mind that because the Jackpot is WiFi capable, most of us use Wifi to send the completed G-Code file to the Jackpotās SD card, by way of the WebUI interface. (This is not the same as trying to do a cut job via wifi, which is a very risky bad move. There is a huge difference between executing a remote G-Code file being fed at real time via wifi, and pre-uploading a completed G-Code in advance to the SD card, and then just running it from the SD card.)
OK so this makes a lot of sense then. Wifi is only the means to transfer the ādataā to the āSDā card from there itās all internal to the Jackpot and whatever interface is allowing you to give commands to the Jackpot again (pendant) would be internal because its plugged right into the GPIO interface.
Iāll have to give this a try then. It does indeed sound more ābullet proofā than either USB or wifi (real time) which I agree would be a recipe for wanted material.
Is there any āresearchā or data on the reason USB is not reliable etc. I mean I trust all of you with my life but if a fella did want a second opinion where would I look.
Generically it is āhardwiredā in that the USB ports on the PC and the ESP are hardwired or internal to each device itās only the USB cable that is again real world wires for the data to transfer from point a to point b.
I realize that itās a two way communication and the Jackpot would need to both receive and send data over USB as would the PC
WOuld that be the āpotentialā bottleneck IE the trouput of the USB protocol versus the Throuput or SPEED of data transfer from the SD card to the Jackpot.
Iād have to let others with more knowledge chime in on pros and cons of USB over wire. Generally speaking, my understanding is that when it comes to live, real time execution of G-Code files, from a standpoint of bandwidth, the ideal is the fattest data pipe, thatās also the shortest data pipe.
Research for the wired usb: how big is your machine? Long usb extension is a lottery ticketā¦
I donāt think the USB is necessarily unreliable, but the computer on the other end? Yeahā¦
A pendant has one job, and generally does it.
A computer is a general purpose machine, and the OS usually treats it as a general purpose machine, even if the only purpose YOU want to out it to is controlling a CNC, the OS mught have other ideas. And if that OS is Windows, it WILL have other ideas. Like āyou havenāt touched the keyboard for 10 minutes. Letās update the OS and reboot!ā (I no longer do large video batch processing on Tuesdays, even though that machine is never supposed to update without my explicit say-so.)
Linux/BSD/MacOS X is generally better. *Nix systems were made for network users, so donāt base stuff on the keyboard/mouse as much, but still sometimes do weird stuff with attached coms, I suspect Gcode senders donāt always keep the processor busy enough so power saving modes kick in.
Anyway, I just donāt use a PC to control the machine, nor do I use a phone or tablet. Much rather have the Gcode local to the controller, and go that way.
all valid responses. For the most part the stuff Iāve done on the Shaeoko was a one-off item that was finished in maybe 20 minutes Max.
With this 2āx4ā Primo Itās highly likely that some jobs will take hours to finish and the Windows deciding to reboot or update or just generally make you have a bad day becomes more āprobableā the longer the CNC job needs to run.
As a former research fellow for the U of M Virtual Reality Design Lab what I was looking for was tests or studies of the latency or efficiency of data transfer over USB. Like USB A was X fast and USB C is X Fast and Ethernet is X fast etc. is it something inherent in the uUSB protocol that is the issue or is it just that one end of the USB cable is attached to a PC running a Microsoft OS?
Please keep in mind that my first modem was 28.8k baud dial up modem from U.S. Robotics In college I wrote programs on MainFrame computers using Punch Cards So Iāve been around the block a few times.
Latency and efficiency arenāt the problem.
Reliability of the end-to-end transfer is.
You hit on one issue- OS stability. Thatās just one element of the problem.
USB cables and USB connectors are not made for running long distances to a flying CNC controller. They are not reliable in the environment that these machine operate in.
Speed/bandwidth/latency is not the issue. gcode only needs to flow at a few lines per second generally.
Thereās plenty of us around here that have a few years on us. I used a teletype terminal as a pre-teen at a local university- which a few decades later now employs me.
IIRC, we started out with 300 baud modems and then upgraded to 1200- which meant I could connect from home when the rest of the family wasnāt on the line.
If you want a suitable interface for a flying CNC controller, the good options would be to use an interface made for that type of environment. RS-422, or even CAN bus would be radically better than USB.
Sadly, at present there are no interfaces for FluidNC like that, and wonāt be unless one of us gets sick of the state of it and makes our own expansion board to implement it.
With a reliable work flow running the job from SD card, I"m not sure anyone would bother.
