EMC_MDIhistory does not respect the requirement of the NIST standard

[zz912]

Branche 2.9 RIP instalation
Tested in Gmoccapy (This issue may also affect other GUIs.)

Here is citation from NIST:

(rs274 v3 - 3.6.1)
Note: It is OK to program M0 and M1 in MDI mode, but the effect will probably not be noticeable, because normal behavior in MDI mode is to stop after each line of input anyway.

Source

HAL component EMC_MDIhistory allow 'stacking' of MDI commands. So normal behavior in MDI mode is NOT to stop after each line of input anyway.

The second problem is that some standards require MDI commands to be executed only with a physical button.
EMC_MDIhistory can execute commands 3 ways:

1. Click on arrow
2. Write command and press enter
3. Double click on previous command

I propose a solution:

1. Add HAL pin to GUI to execute MDI command
   The LinuxuCNC integrator will produce a physical button.
   The signal from the physical button and the HAL pin halui.program.is-idle will be connected to the HAL component and2. This will ensure that the physical button is ignored during MDI command execution.
2. Prohibition of executing MDI commands by click on arrow, write command and press enter, double click on previous command.
   This disable MUST be configurable.
   In Gmoccapy it might look like this:
   

[Sigma1912]

Are you filing this issue simply because the behavior is not as described in the NIST document or does this create other issues?

[zz912]

Are you filing this issue simply because the behavior is not as described in the NIST document

Yes

or does this create other issues?

I can't build a machine that meets the standards.

It is not standard software bug.

[Sigma1912]

So do you see this as a GUI issue or an issue with the underlying code base?

I came across another violation of the NIST standard recently regarding G52/G92 deactivation on M2/M30:
#2921

Personally I find it rather unfortunate that a standard configuration of LinuxCNC does not follow the standard NIST behavior.
The problem is that these violations are not necessarily bugs but can be intentional. In the case of the nonstandard G52/G92 behavior it is actually tested for when we run the build tests. In the case of MDI stacking it is likely the same.

[zz912]

So do you see this as a GUI issue or an issue with the underlying code base?

Can you explain me what is "underlying code base"?

Personally I find it rather unfortunate that a standard configuration of LinuxCNC does not follow the standard NIST behavior.
The problem is that these violations are not necessarily bugs but can be intentional. In the case of the nonstandard G52/G92 behavior it is actually tested for when we run the build tests. In the case of MDI stacking it is likely the same.

Some people wants stacking MDI stacking some people like me wants the same behavior like NIST.
https://forum.linuxcnc.org/gmoccapy/51209-we-allow-stacking-of-mdi-commands-is-it-ok?start=0
It must be configurable.

[Sigma1912]

What I meat is, should the individual GUIs be responsible whether stacking is allowed or not or should the python interface do it?

[zz912]

The LCNC integrator should be responsible for stacking MDI commands or not stacking. A person who makes a machine.

Small printer with small stepper motor - it doesnt matter.
Big machine with servos - I recommeneded use standards.

The LCNC integrator can be person who use only HAL language.

[zz912]

Hello,

I don't want to debate whether the MDI queue is a matter of the NIST standard or another standard. Let's leave that to the LCNC integrators.

I would like to recap the possibilities.

Simple (no graphic change):

1. disable the MDI queue
2. enable MDI queue
3. make disable/enable MDI queue configurable (I prefer this)

More complex (graphical change):

4. enter blocks of MDI commands (This is the best solution)

This is how a friend has it on an old CNC machine with a sinumerik from the 80s. It still has a green CRC screen.
He can enter several lines of MDI commands into the MDI screen.
Once he enters this, he starts this sequence with the physical green button. He would like this solution in the current LCNC as well.
In Gmoccapy's implementation, it might look like this:

Currently, the Enter key executes the current line of MDI code.
If we decided on this solution, the Enter key should create another line. The execution of this block would be the blue arrow, or just the HAL pin. MDI blocks queuing is disabled.

[andypugh]

Personally I prefer the current behavior to multi-line entry. It suite me to have the machine drilling the first hole / making the first pass while I am typing in the next hole position or endpoint.

Are you sure that you are interpreting the nature of the document correctly? All that I can find is a NIST report from 2000 describing their implementation of an RS274 interpreter. I don't think that it is necessarily clear that this has the status of a NIST standard.

If you are looking for an official, issued standard then maybe you need to choose one of the following:

"The first standardized version of G-code used in the United States, RS-274, was published in 1963 by the Electronic Industries Alliance (EIA; then known as Electronic Industries Association).[4] In 1974, EIA approved RS-274-C, which merged RS-273 (variable block for positioning and straight cut) and RS-274-B (variable block for contouring and contouring/positioning). A final revision of RS-274 was approved in 1979, as RS-274-D.[5][6] In other countries, the standard ISO 6983 (finalized in 1982) is often used, but many European countries use other standards.[7] For example, DIN 66025 is used in Germany, and PN-73M-55256 and PN-93/M-55251 were formerly used in Poland."

But I doubt that any of the major G-code dialects conforms to any of these standards, but will rather be a superset of them.

LinuxCNC has moved on a lot from the 2000 report. For example the 2000 report does not include G76 lathe threading.

Personally I see LinuxCNC as the inheritor of the NIST "standard" and just as they were making it up as they went along, so are we. We are still closer to that 2000 report version than most of the commercial G-code variants.

[zz912]

I'm not an expert on NIST standards. That's why I prefer configurability. On the other hand, I'm not the only one who prefers to ban the MDI queue.
https://forum.linuxcnc.org/gmoccapy/51209-we-allow-stacking-of-mdi-commands-is-it-ok?start=0#289684