simulation

I should have clarified. I didn't mean to say that this is a "bad idea" or even that it isn't useful. But is it worth the effort?

What is a bad idea is the way it is implemented on the Fanuc machines I work with (most of which don't even have the option of displaying the tool paths on screen, an option the machine builder didn't spring for). On those machines pressing the "dry run" button simply disables movement of all or just the Z axis, exactly the same way as disconnecting the step output on an open loop step/dir machine would. This is already not good, because it guarantees loos of position if you don't end the dry run in the exact position you started it. What's worse is that these Fanuc machines have absolute encoders and if you do mess up the position, not even re homing the machine can correct the problem, only a power cycle will fix it. That is what I was saying is a "bad idea"

You could implement a very similar dry run in Linuxcnc simply in hal and have better behavior with regard to retaining position (even with open loop steppers).

In Hal connect a several mux2 components between the position feedback inputs (joint.N.motor−pos−fb) and the real position feedback outputs and a tristate_float between the position command and the stepgen or PID. The mux2.N.in0 would go to the original feedback source and mux2.N.in1 would connect to joint.N.motor−pos−cmd. Then trigger all the muxes and tristates (might need to invert one of these) with an output from a real button on the user panel or one on a VCP. Ending the dry run would cause an instant following error and machine shut down if the end position didn't match the start. But unlike Fanuc upon re-enabling the machine the position should be correct it's self (no re-homing required)

In the first instance I can think of saving the state and recovering it to enter and exit the test mode.
Fanuc-Fagor-siemens etc, you enter a graphic function to test a program. Linuxcnc is always in graphic mode, that's why I came up with the idea of ​​putting a gui button to just enter or exit the test mode.

now I have no idea how linuxcnc can be disconnected from the outside world and that everything continues to run in sofware mode

thanksss

I thought just described one way above. Linuxcnc only sees what you have connected to it, and if you disconnect it then...

If the idea of having a following error alarm pop up scares you, (and maybe it should) the easiest work around for that would be adding adding something that places the machine in the off state (such as the hal pin motion.enable) when the dry run is released before the following error can be triggered but the net effect would be the same. When Linuxcnc is in the machine off state (F2) it does not care what the feedback position is, and when it is taken to machine "on" or enabled it mearly sets the current feedback position as the commanded position. Therefore any out of position-ness would be automatically corrected.(without movement.)

RobotMatic wrote:

In the first instance I can think of saving the state and recovering it

.

That wouldn't actually be necessary, the real current position would be automatically preserved by the original feedback device be it the encoder counter or the step generator. The only problem would be when ending the dry run if the real feedback position doesn't match the commanded position. In which case the following error alarm would trigger, and the machine would be placed in the disabled/off state. Once in the off state Linuxcnc would set the commanded position to match the current feedback position. Press (F2) to turn on/enable the machine and every thing should be back to normal. (If the positions matched nothing would happen.)

Maybe, but when you can't program C to save your life this is what your left with.

Seems to me a way to temporarily disable the position command and reset the commanded position to be equal to the feedback position, could also be part of the solution to a question on another thread (the 5-axis switch between TCP and joint kins one.)

I've added an experimental branch for implementing a
dryrun facility: dgarr/dryrun (based on the master
branch):

github.com/LinuxCNC/linuxcnc/commits/dgarr/dryrun

In dryrun mode, you can jog axes, issue mdi commands or
run gcode programs and the axis gui display acts
normally -- however, no hal pins or motion status items are
updated.

A sim config using a pyvcp panel is provided:
configs/sim/axis/dryrun/dryrun.ini

Ref: github.com/LinuxCNC/linuxcnc/blob/dgarr/...m/axis/dryrun/README

The video below shows the axis gui preview path and
its dro display while running after selecting dryrun
mode. The halshow panel shows that the halpins for
positioning commands (motor control) are unaltered
while the dryrun is active.



====================================================

Notes:

1) The machine must be homed and ON in order to start
dryrun.

2) halpins set by gode commands like M62-65 (digital
outputs) and M67-68 (analog outputs) are not changed in
dryrun mode.

3) ancillary guis (like halui) are not affected. The
provided halpin motion.is-dryrun can be used to manage
their outputs.

4) Dryrun cannot be started when a program is running
in normal mode (stop the program first). Similarly,
dryrun cannot be stopped when running a program (stop
the program first). Mesages are issued for these
attempts.

5) Under some conditions with the axis gui, the
manual tab must be selected to start or stop dryrun.

6) halpins are read during dryrun but acknowledgement
varies:

a) inputs to task (example: halui.program-pause,resume)
are processed.

b) inputs to motion (example: limit switches) are
ignored as motion status is not updated during dryrun.
(This is subject to change for selected inputs)

====================================================

The branch can be built as a Run-in-place (RIP) or
obtained from the buildbot as a 'scratch branch (for
buildbot-supported operating systems) per the
instructions:

buildbot.linuxcnc.org/
====================================================

excellent !!!! thank you very much!!! I'm going to modify a lathe and try. thank you very much!!!!!!

hi

I can't understand how I can incorporate the function, sorry for the question but I see many codes and I don't know where to start.

I understand how it works and the instructions to make it work, but I don't know how to implement

This function is excellent !!! I work intensively with compensation and I really believe that this implementation is very important for the project

Could you attach the codes and tell me where to put them. Thanks a lot

... I don't know where to start.

Suggestions:

1) Read the integrator docs for the facility:
buildbot.linuxcnc.org/doc/scratch/v2.9.0...tegrator/dryrun.html

2) Install the 'scratch' dgarr/dryrun branch deb package from the buildbot
OR
3) Make a run-in-place build from a recent git checkout

4) Run and study the simulation config:
configs/sim/axis/dryrun/dryrun.ini
(No hardware or connections are required for sim configs)

5) Adapt to an existing hardware config following the docs
and the simulation examples.
Ref: buildbot.linuxcnc.org/doc/scratch/v2.9.0...rdware_configuration


Notes:

a) Instructions for obtaining buildbot scratch debs:
buildbot.linuxcnc.org/

b) buildbot scratch debs are available for a limited number of
days after an update -- a rebase update pushed today 3feb20

c) The experimental dgarr/dryrun branch is based on master branch
2.9~pre* and is force-pushed.

d) Instructions for building (run-in-place)from git:
linuxcnc.org/docs/master/html/code/building-linuxcnc.html
The branch to checkout is named dgarr/dryrun

e) The buildbot docs expire after a number of days but the
ascii doc text file is available at:
github.com/LinuxCNC/linuxcnc/blob/dgarr/...ntegrator/dryrun.txt