Problem: Problem with the status information sent by FluidNC about fluidnc HOT 30 CLOSED

The communications you show from FluidNC do not appear to be correct. They also do not show the outgoing commands. It might be better if you demonstrate the problem with a "dumb" serial terminal to eliminate any auto generated commands from the sender.

FluidNC is compatible with Grbl by default.

If you send "g1 g90 f1000 x5 all you should get back is a an OK. What you are showing is a response to $I and (2) ? status requests.

Standard Grbl will not send continuous status updates during a move without periodic ? status requests being sent.

We also have a FluidNC feature for automatic status reporting. You can read more about it here.

http://wiki.fluidnc.com/en/support/interface/automatic_reporting

UART Channels also have automatic reporting features.

http://wiki.fluidnc.com/en/config/uart_sections#uart-channels

===== Grbl Via Serial Terminal ======

Grbl 1.1g ['$' for help]
[MSG:'$H'|'$X' to unlock]
$X
[MSG:Caution: Unlocked]
ok
G1 G90 F1000 X5
ok

====== FluidNC Via Serial Terminal

Grbl 3.7 [FluidNC 3.7.13 (wifi) '$' for help]
[MSG:INFO: '$H'|'$X' to unlock]
$X
[MSG:INFO: Caution: Unlocked]
ok
G1 G90 F1000 X5
ok

====== FluidNC with auto reporting Via Serial Terminal

Grbl 3.7 [FluidNC 3.7.13 (wifi) '$' for help]
[MSG:INFO: '$H'|'$X' to unlock]
$X
[MSG:INFO: Caution: Unlocked]
ok
$report/interval=100
[MSG:INFO: uart_channel0 auto report interval set to 100 ms]
ok
<Idle|MPos:0.000,0.000,0.000|FS:0,0|WCO:0.000,0.000,0.000>
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0]
G1 G90 F1000 X5
ok
<Run|MPos:0.000,0.000,0.000|FS:225,0|Ov:100,100,100>
<Run|MPos:0.125,0.000,0.000|FS:315,0>
<Run|MPos:0.500,0.000,0.000|FS:465,0>
<Run|MPos:1.125,0.000,0.000|FS:615,0>
<Run|MPos:1.987,0.000,0.000|FS:577,0>
<Run|MPos:3.050,0.000,0.000|FS:427,0>
<Run|MPos:3.912,0.000,0.000|FS:277,0>
<Run|MPos:4.525,0.000,0.000|FS:127,0>
<Run|MPos:4.887,0.000,0.000|FS:0,0>
<Idle|MPos:5.000,0.000,0.000|FS:0,0|WCO:0.000,0.000,0.000>
[GC:G1 G54 G17 G21 G90 G94 M5 M9 T0 F1000 S0]

from fluidnc.

I wonder if your program is expecting the controller to automatically reset and issue a Grbl startup message when the serial connection is established? Arduino hardware auto-resets on USB serial connection establishment; ESP32 hardware typically does not. Auto-reset would be very bad in our case because we support multiple control channels that can come and go. If a new connection caused a reset, it could interrupt a job that is already in progress that was started from a different channel.

This diagram shows a robust connection establishment procedure that works on any Grbl-protocol controller, whether or not it auto-resets. It handles the possibility of various kinds of alarm states that could block certain commands.

It is possible to reset FluidNC by pulsing the RTS modem control signal active for a few hundred milliseconds, while leaving DTR inactive. That might be an avenue for an initial test, but it would not be considered good behavior for GrblGru to reset every time that it connects.

from fluidnc.

Some more Info here.

http://wiki.fluidnc.com/en/features/grbl_compatibility

from fluidnc.

First of all, thank you very much for your quick help.

Sorry, you're right, it was unwise of me to use my own debug output.
I was fooled by it and jumped to a premature diagnosis.

I have now taken a closer look at the process.
After sending a command, I request status information at intervals with "?".
This continues until the IDLE, HOLD or ALARM status is reached.

The time interval is generated by simply counting down an integer.
In this loop I use the function Sio.BytesToRead() to check whether the controller has sent anything.
And here I now have a different behavior than with the other controllers.
The call of Sio.BytesToRead() takes much longer with FluidNC. This makes my time interval for sending '? is so large that instead of every second, new status information is only requested every minute.

Can you recommend another type of query or can I influence the behavior somewhere?
What am I doing wrong?

Many thanks for your time

from fluidnc.

It is hard to help without knowing the rest of the code. It could be that the extra [MSG:...] traffic in FluidNC is highlighting some efficiency in your RX processing. You could try setting $Message/Level=None to reduce those as a test.

There are a lot of messages at startup, but not too many in normal run mode. The messages are very helpful, so users will probably want to keep them set to "Info" and occasionally "Debug"

http://wiki.fluidnc.com/en/features/commands_and_settings#messagelevel

from fluidnc.

The typical time for FluidNC to respond to ? is on the order of a few milliseconds. If you are seeing much longer time there could be a problem in your serial setup. Using a serial terminal like FluidTerm or TeraTerm, I can hold down the ? key on my keyboard and get responses back as fast at the keyboard will auto-repeat. That speedy behavior is true in both Run and Idle states.

If you are experiencing delays, I wonder if there could be something about your serial port driver configuration that is causing transmission or reception delays? Some system interfaces can be configured to, say, send only after a complete line has been acquired. In that case, a ? might be held up until a newline follows it. I know that you don't seem to have such problems with classic GRBL, but I am just fishing for an explanation. I can assure you that FluidNC itself does not hold up reception and processing of ? pending other characters, instead responding to it as soon as possible.

You might also consider using the FluidNC auto-reporting feature. It eliminates the need for periodic polling with ?. With auto-reporting enabled, when FluidNC is in idle state, any state change will cause a status report to be issued. When in Run state, status reports will be issued at a configurable interval so DROs and visualizations can proceed smoothly. But it is probably a good idea to figure out your status delay problem first, in case there is an underlying issue that needs to be resolved.

from fluidnc.

BTW, I have a little experience with GrblGru. Before I became a Grbl_Esp32/FluidNC developer, I spent some time trying out GrblGru and making a 3D model of one of my machines. If you get stuck and are willing to let me look at your source code on a confidential basis, I might be able to help.

from fluidnc.

Thank you very much for your ideas and suggestions to solve the problem. It is always very difficult when you don't have all the information available.

I have tested auto-reporting. That also looks very good. But I would rather fix the problem.
Also tried "$Message/Level=None". Unfortunately without success.

I don't think FluidNC is sending anything at this point, because I added some wait times after opening the interfaces.
I also query the version, set some parameters and then go into the endless loop.

I have now programmed the following sequence only for testing.
Everything else is out of function.

• Open interface - Sio.Open()

• Query FluidNC version - Sio.Write("$I\n");

• Set parameters - e.g. Sio.Write("$10 = 0\n");

• Wait for start command - MessageBox.Show("Press key to start"); // To be sure that FluidNC has done all inits

• Call CheckTimer() - Simple endless loop

 public void CheckTimer()
    {
        int timer = 0;
        CounterRequest = 200000;

        while (true)
        {
            if (Sio.BytesToRead > 0)
            {
                // Do nothing
            }

	// Just to see how quickly the loop is completed
            if (timer % 1000 == 0)
                AddMessage(MessageTypes.LEFT_WINDOW, "#");

            if (timer-- < 0)
            {
                timer = CounterRequest;
               // Sio.Write("?");
            }
        }
    }

The problem is the pure call of Sio.BytesToRead().
The routine always returns 0. This means that nothing was received.
But the call takes a lot of time under FluidNC !
If I comment out the call, the loop runs much faster.
With the other controllers, the loop always runs quickly.

from fluidnc.

I am guessing that you are using C# and .NET based on the names of some functions. I have no direct experience with C# and .NET but, based on https://learn.microsoft.com/en-us/dotnet/api/system.io.ports.serialport.-ctor?view=dotnet-plat-ext-8.0, I wonder what you have ReadTimeout and WriteTimeout set to.

from fluidnc.

Yes, your assumption is correct. I use C#.
To be honest, I have never initialized the TimeOut values.
But I have tried it now. Unfortunately without success.

// The original Init

    Sio.PortName = Port;
        Sio.BaudRate = BaudRate;
        Sio.Parity = Parity.None;
        Sio.StopBits = StopBits.One;
        Sio.DataBits = 8;
        Sio.Handshake = Handshake.None;
        Sio.ReadTimeout = 10000;

// Just added

// Set the read/write timeouts
        Sio.ReadTimeout = 500;
        Sio.WriteTimeout = 500;

from fluidnc.

Try setting them much shorter.

from fluidnc.

// Set the read/write timeouts
Sio.ReadTimeout = 5;
Sio.WriteTimeout = 5;

Same result

from fluidnc.

Counting the iterations of the loop does not seem like it would be very consistent. Computer speed and rx activity would greatly affect the frequency. It is probably better to record current and compare to a future time (something like millis() ).

If Sio.BytesToRead > 0 does return true, what removes the received bytes?

from fluidnc.

It is possible to enter the timer value in the GrblGru settings.
I wanted to create as simple a stable interface as possible.
Hence the polling instead of any interrupt routines.

int Count = Sio.BytesToRead() returns the number of characters in the Sio buffer.
If Count is > 0, I read the buffer with "string indata = Sio.ReadLine();"
However, I have removed all of this in the test program.

from fluidnc.

Were your timeout experiments done on the test code or the real code?

from fluidnc.

I will think some more about this when I get back from the restaurant. The windows serial driver has many configuration options and the C# layer above it adds additional complexity

from fluidnc.

I did the timeout experiments earlier only in the test code.
When I do it in the real code, I already get error timeout messages for the following values, which
but probably only occur because I am not handling this case. If I increase the values to 500, I don't get any more error messages. However, the original problem is still there.

   // Set the read/write timeouts
        Sio.ReadTimeout = 50;
        Sio.WriteTimeout = 50;

from fluidnc.

Show the real code.

You should only get timeouts if you do a read when Sio.BytesToRead == 0. You should not read when that is the case.

from fluidnc.

No, I'm sure, I never read when Sio.BytesToRead == 0.
Then there is also an exception that I catch.

Because I am of the opinion that the call of Sio.BytesToRead() is the cause of the problem, I have only changed my real code routine in one place.

I created a handler that sets a static variable when characters are received.

Sio.DataReceived += new SerialDataReceivedEventHandler(DataReceivedHandler);

public static bool bReceiveData = false;
public static void DataReceivedHandler(object sender, SerialDataReceivedEventArgs e)
{
bReceiveData = true;
}

Instead of querying Sio.BytesToRead(), I now check bReceiveData.

 // if (Sio.IsOpen && Sio.BytesToRead > 0)
    if (Sio.IsOpen && bReceiveData)

That works ! I can jog all axes and also start GCode.
GrblGru works normally as with all other controllers.

But after some time problems occur. The program stops intermittently.
I suspect that the alternative function is not stable and it can happen,
that information is lost.

However, this confirms that the sole cause is to be found in Sio.BytesToRead.
Why does it take so long to query this value?
At the moment I don't know how to determine this time in a simple way.

from fluidnc.

Read this for some insight into why things like BytesToRead can take a long time . https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddser/ns-ntddser-_serial_timeouts

Multiprocessing operating systems typically do not like for programs to poll for events in a tight loop because if all programs were written that way, they would always be fighting each other. As a result, polling-style interfaces like BytesToRead are often designed with timeouts so when they have nothing to report, they delay for some (usually configurable) time to give other processes a chance to run. It can be tricky to learn exactly how that works in specific circumstances.

from fluidnc.

Hmm, I don't understand that.
BytesToRead is a function that does not wait for something, but only checks whether something has been received.
That should be very fast. Only when something has been received do I read the characters.
And of course I have Thread.Sleep(10) built in, otherwise the whole thing would certainly not work at all.

I would be very interested to know whether this is due to my ESP32.
You said that you have used GrblGru before. I hope I'm not being impertinent.
But can you maybe try to start your controller with GrblGru in controller mode "GRBL V1.x".
I have read that you can specify the version message under FluidNC. If you enter a "grbl" message there, GrblGru should not complain.
I won't be able to make it today. But I will try to flash my ESP32 with GrblHAL tomorrow to see if there are any problems.

from fluidnc.

BytesToRead is a function that does not wait for something, but only checks whether something has been received.

The documentation that I mentioned earlier does not say anything at all about the timing (i.e. whether or not it waits), only what it returns. It does say that the return value includes both the buffer inside the serial driver and also buffering inside the SerialPort object. In order to get the serial driver info, it would have to call into the Window operating system. The only way that I know to obtain that information from the Windows COMM driver is to call ReadFile() on the COMM handle. That inherently is a timed operation as described in https://learn.microsoft.com/en-us/windows/win32/devio/time-outs and https://learn.microsoft.com/en-us/windows/win32/devio/read-and-write-operations . So, unless you have looked at the .NET source code, I don't think it is possible to conclude that BytesToRead never waits.

from fluidnc.

I am not so familiar with the internal processes of the SIO routines.
I can also very well imagine that I am not doing something optimally.
But on the other hand, I already have so many different hardware controllers and different controller systems
with the same functions. Only with ESP32 and FluidNC it doesn't work.

I have to go to bed now. Many, many thanks for your great help. Super support!
I'm sure we'll find the cause. This is the kind of error that makes you say afterwards :
"Well, that was easy, why did it take you so long?" :)

from fluidnc.

I downloaded GrblGru Beta 5.2.9 .

Using FluidTerm, I set the startup message to look like plain Grbl by sending

$startup/message=Grbl 1.1f [\H]

Then I ran GrblGru, using COM13 using these settings

Everything I tried seems to work just fine. I jogged, ran a couple of example gcode files, made a macro to issue some FluidNC special commands like $SS, made a macro to run a GCode file from SD ($sd/run=u.nc) etc. I saw no strange behavior whatsoever. The status reporting worked exactly as it should with no noticeable lag.

from fluidnc.

Wow, I didn't expect that. Thanks again for testing!
What type of controller did you use?
The name of my controller is "Espressif ESP32 WLAN Dev Kit Board Development Bluetooth Wifi v1 WROOM32 NodeMCU"

I have just flashed it once with GrblHAL, and the result is ... that it doesn't work either !!!!
So it's definitely not a FluidNC problem, but more an ESP32 problem.
Sorry for bothering you with this. :(

Do you have an address of a forum where I can get information about the internal things of the ESP32 ?

from fluidnc.

I used an ESP32 Mini board for this particular test, but I routinely use many other ESP32 modules and they all behave the same with regards to communication with senders. The modules that we recommend as being the most trouble-free are DevkitC modules from Espressif like this one for example. https://www.digikey.com/en/products/detail/espressif-systems/ESP32-DEVKITC-32UE/12091813 . Whether it has built-in or external antenna does not matter except for wifi range.

That said, I have used more different WROOM modules than I can count and most of them work. I have seen broken micro-USB connectors and, rarely, failed USB-Serial chips. The quality ones that cost in the $10 range have CP210x USB-Serial chips which hardly ever cause problems. The super-cheap ones from no-name Chinese suppliers often have CH340 USB-Serial chips that can be flaky.

With regards to forums, Espressif has one that is somewhat definitive if you happen to get an answer from the manufacturer, but usually I just Google.

This page on our wiki has some info http://wiki.fluidnc.com/en/support/controller_design_guidelines

from fluidnc.

The most common problems with random no-name modules are

1. Sometimes they won't go into download mode when you try to FLASH new firmware; sometimes that can be worked around by pressing the BOOT0 button at just the right time.
2. Some ESP32 boards have the wrong number of pins to plug into the sockets on Bart's controller boards.

from fluidnc.

I had no idea that there were so many differences in quality.
It looks like I was just unlucky with my purchase.
Then I won't even try to get any more information, but instead
buy the board you recommended.

Thanks again for your help.
If you should deal with GrblGru again and have a wish, please let me know. :)

from fluidnc.

One thing that caused me problems when testing GrblGru: The default setting of the macro editor resulted in Notepad being used. Then it auto-created a macro file which ended up being named .dat.txt . That didn't work, and fixing it took a lot of trial and error. I eventually realized what was happening, and where the file was located. I deleted .dat.txt and set the editor to Notepad++ (which then got me into the whole "update Notepad++" cycle). Eventually I got it to work.

I realize that it's not your fault that Notepad does this stupid thing, but it does impact the user experience when the default setup results in a mess that is tricky to fix. The manual didn't mention this possibility so I had to work it out the hard way. I suppose that one mitigation would be to accept .dat.txt as an alternative.

The other tricky thing is that many editors do not put .dat extensions in the acceptable list for file open dialogs, so you have to know to change the filter to "all files"

from fluidnc.

Closing as resolved

from fluidnc.