Advanced Search

Thank you very much for investigating this further and for explaining what you found.

You are absolutely right.

With 400 steps/mm and HOME_OFFSET = 6, the corresponding physical home-switch position in the simulator is:

With the previous switch position at 4000 steps (10 mm), the difference is:

which explains almost exactly the offset you observed between AXIS and the simulator.

So this is not a problem in the switch implementation. The important point is that the positions in virtual-io.conf describe physical switch positions in the simulator's step coordinate system, while HOME_OFFSET tells LinuxCNC which machine coordinate corresponds to the home-switch position.

I agree completely that this is not explained clearly enough at the moment. A user should not have to discover this relationship by trial and error.

I will add a clear explanation and an example directly to virtual-io.conf and also make sure the documentation describes the relationship between the virtual switch position, steps/mm and HOME_OFFSET.

Thank you for taking the time to investigate this instead of simply reporting that something was wrong. Your observation identified a real weakness in the documentation, and your explanation makes the intended behavior much clearer.

This kind of feedback is extremely valuable for the project. Thank you.

Material movement won't work in `machine_test`; it is just a simple configuration for testing purposes. In my configuration, I write the following code in the custom qtdragon handler file:

if (hal.component_exists("vismach")) == False:
    c = hal.component("vismach")
    c.newpin("mat_X_min", hal.HAL_FLOAT, hal.HAL_IN)
    c.newpin("mat_Y_min", hal.HAL_FLOAT, hal.HAL_IN)
    c.newpin("mat_Z_min", hal.HAL_FLOAT, hal.HAL_IN)
    c.newpin("mat_X", hal.HAL_FLOAT, hal.HAL_IN)
    c.newpin("mat_Y", hal.HAL_FLOAT, hal.HAL_IN)
    c.newpin("mat_Z", hal.HAL_FLOAT, hal.HAL_IN)
    c.newpin("mat_X_max", hal.HAL_FLOAT, hal.HAL_IN)
    c.newpin("mat_Y_max", hal.HAL_FLOAT, hal.HAL_IN)
    c.newpin("mat_Z_max", hal.HAL_FLOAT, hal.HAL_IN)
    c.newpin("hide-chuck", hal.HAL_BIT, hal.HAL_IN)
    c.newpin("hide-konik", hal.HAL_BIT, hal.HAL_IN)
    c.newpin("os3", hal.HAL_BIT, hal.HAL_IN)
    c.ready()


STATUS.connect('graphics-gcode-properties',lambda w, d: update_gcode_properties(d))
def update_gcode_properties(props):
    if props != None:
        print ("update update_gcode")

        s = linuxcnc.stat()
        s.poll()

        print("MatPoz        :", s.g5x_offset[2])   

        property_names = {
                'x': "X bounds:",'x_zero_rxy':'X @ Zero Rotation:',
                'y': "Y bounds:",'y_zero_rxy':'Y @ Zero Rotation:',
                'z': "Z bounds:",'z_zero_rxy':'Z @ Zero Rotation:',
                'a': "A bounds:", 'b': "B bounds:",
            }
        #print (props)
        X_poz_min = float((props.get('x_zero_rxy').split())[0])
        Y_poz_min = float((props.get('y_zero_rxy').split())[0])
        Z_poz_min = float((props.get('z_zero_rxy').split())[0])
        X_poz = float((props.get('x_zero_rxy').split())[4])
        Y_poz = float((props.get('y_zero_rxy').split())[4])
        Z_poz = float((props.get('z_zero_rxy').split())[4])
        X_poz_max = float((props.get('x_zero_rxy').split())[2])
        Y_poz_max = float((props.get('y_zero_rxy').split())[2])
#        Z_poz_max = float((props.get('z_zero_rxy').split())[2])
        Z_poz_max = (s.g5x_offset[2])

        # G20 -> G21
        if props.get('gcode_units') == 'in':
            X_poz_min *= 25.4
            X_poz *= 25.4
            X_poz_max *= 25.4

            Y_poz_min *= 25.4
            Y_poz *= 25.4
            Y_poz_max *= 25.4

            Z_poz_min *= 25.4
            Z_poz *= 25.4

        print ("mat_X_min =", X_poz_min,"    mat_X_max =", X_poz_max,"    mat_X =", X_poz)
        print ("mat_Y_min =", Y_poz_min,"    mat_Y_max =", Y_poz_max,"    mat_Y =", Y_poz)
        print ("mat_Z_min =", Z_poz_min,"    mat_Z_max =", Z_poz_max,"    mat_Z =", Z_poz)
        hal.set_p("vismach.mat_X_min", X_poz_min)
        hal.set_p("vismach.mat_X", X_poz)
        hal.set_p("vismach.mat_X_max", X_poz_max)
        hal.set_p("vismach.mat_Y_min", Y_poz_min)
        hal.set_p("vismach.mat_Y", Y_poz)
        hal.set_p("vismach.mat_Y_max", Y_poz_max)
        hal.set_p("vismach.mat_Z_min", Z_poz_min)
        hal.set_p("vismach.mat_Z", Z_poz )
        hal.set_p("vismach.mat_Z_max", Z_poz_max)

So, it writes the dimension positions to the HAL pins, and then, in the handler file, it reads the material dimensions from those pins (just like in that commented-out section that constructs the material).

This function is located in the qtdragon handler file because it isn't called within the vismach file itself when launching vismach in a standalone window; however, this approach allows for launching a second (or subsequent) vismach window without issues (e.g., to test with different parameters).

I'm constantly making tweaks—like saving the machined material to an STL file.
If you have any interesting ideas, let me know.
 

Rod, awesome video! I actually understood a lot more of that sample INI file, definitely had mistakes. hopefully now it is better (but seems like not yet good because it is not working completely).
I have attached:
1) mb2hal.hal file, which at the moment only loads mb2hal module
2) mb2hal.ini file
3) modbus.png which shows few hal pins of the mb2hal module. what I find a good sign there is that first transaction for reading the registers seem good, no errors are accumulated there
4) modbus error.png shows the error message in terminal when I started LinuxCNC there, maybe that is helpful for understanding what am I missing
5) VFD manual
6) VFD modbus register map

I have a suspicion that "First element" in mb2hal.ini is not correct because of the values that are reported on hal pins.Values of those hal pins match following settings from VFD: P-01 (max speed) is set to 24000 and P-02 (min speed) is set to 1800 and P-03 accel ramp time and P-04 decel ramp are both 6.0 seconds

And now as I was writing this, I checked - if I change P-04 parameter (decel time) to 7.0 seconds, mb2hal.status.coast_stop.int immediately changes value to 700 and changing P-03 to 5.6 seconds changes mb2hal.status.reset.int to 560 - hooray I have some basic communication going!
I chose those names according to functions of first 4 bits of register 1 that show status of VFD - I thought that they would reflect values of the first 4 bits, but now I see that they are integer type hal pins, so now I am confused which registers am I looking at.

I took the "First element" value of 128 from very bottom of page 36 of VFD manual (section 8.4 "Modbus register map")

Could you please hint me what am I doing wrong? Because from that register map I understand that register 4 holds accel / decel (from modbus register map it seems that it is one value used for both accel and decel but I proved that those are 2 separate values received from VFD) and I am somehow reading that but I do not see in that map any register that shows min and max speed settings. Where do those come from (got curious and checked - hal pin values are updated immediately when I change those settings in VFD)?

And it seems obvious that if the first transaction is not reading the register that I thought it would then other 2 transactions will not write the register that I thought they would and they produce those errors...

Thanks in advance!

I haven't tested 0.1.2, but I think I found the reason for the zeros moving apart.
In a normal machine, zero is counted from the point where the limit switch is actuated, but here the position of the limit switch is apparently set as relative to zero...
In my settings HOME_OFFSET = 6, so limits set Z max must be 2400 and not 4000 as it was.
After this change, the zeros in both windows are in place.
So there's nothing to fix, but some comment in the virtual-io.conf file would be helpful.

fmueller wrote:

[b][b][code][code][code][code][b][url=https://github.com/FredericM88/linuxcnc-sim/releases/tag/v0.1.2][b]Could you try v0.1.2 with the new Phase 3 configuration and see whether the Z offset still occurs on your system?[/b][/url][/b]

[/code][/code][/code][/b][/code][/b]
 

It's late, so I do test v0.1.2 rather tomorrow.
Bellow is what was and I described above.
 

Thanks for the detailed feedback and also for the launcher script!

We haven't had the opportunity to test your script yet, but we will definitely take a closer look at it. Starting LinuxCNC and the simulator together with a single command is a very useful idea.

I went through the three points you mentioned and used them to update the Phase 3 example.

Working area

You were right that the previous working area was much too small for a realistic milling machine example.

The Phase 3 machine now uses:

The virtual limit switches were updated accordingly and are located 1 mm outside the normal working area.

Z homing

I also changed the Z homing as you suggested.

X and Y still home toward their minimum switches, but Z now homes upward toward the maximum/home switch. The Z switch is therefore approached from below with a positive HOME_SEARCH_VEL.

Z offset between AXIS and the simulator

This was the point I was most interested in, so I tried to reproduce it deliberately.

For the test I placed the physical Z home switch at +1 mm and configured:

This means that the physical switch position is intentionally different from the final G53 Z0 position.

I tested the complete homing sequence with LinuxCNC 2.10.0-pre2.

Z approaches the upper switch from below, backs off, performs the slow latch approach and finally moves back to G53 Z0.

After homing, both AXIS and the simulator showed exactly Z0.

I then commanded:

AXIS showed:

and the simulator showed exactly:

at 400 steps/mm.

I also checked the simulator's min/max switch implementation and added an explicit automated test for approaching the Z maximum switch from below, including its hysteresis behavior.

So far I have not been able to reproduce the several-millimeter Z offset you are seeing.

These changes are now included in v0.1.2:

linuxcnc-sim v0.1.2

The complete simulator test suite also passes with the new configuration: 91/91 tests passed.

Could you try v0.1.2 with the new Phase 3 configuration and see whether the Z offset still occurs on your system?

If the offset is still there, could you send me your LinuxCNC .ini and .hal files, and your virtual-io.conf if you changed it?

Then I can reproduce your exact configuration instead of guessing where the difference comes from.

Thanks again for testing the simulator. Your feedback already resulted in several improvements to the example configuration.

I have converted my old vismach to this VTK and i must say that i am impressed with it!
My configuration is only a simple 3 axis machine.
In the attachments, my configuration (vtkvismach is in the config folder) and 3d files (these go in your nc_files folder)

Some pro's for the new VTK implementation, in my opinion:

• Smaller stl from freecad (old vismach you needed to export as .ast, now normal .stl)
• In less lines you can configure your machine.
• Model groups are a real nice way to toggle off machine components you don't want to see during simulation.
• Transparent stock!
• Runs from you config folder stand alone.
• You can start it while your program is already running, or even if your machine is not homed yet.
• Quick switching of the viewing planes.

I found out that (in any case by HUD) that using hal pin's and don't create hal pins with the vtkvismach script makes you able to restart vtkvismach without restarting linuxcnc since you don't create double hal pins. For creating your model this faster.
The pins necessary for my HUD are now created in "custom.hal".
 
Also i added a few extra lines (classes) to vtk_vismach.py, some for my own preferences/use

• ini_work_file:
  ini file reading, i use a ini file in the NC folder to specify my Job, in the ini file you can state your workpiece, raw stock and the work holding. In my example the files are read from the nc_files folder. 
  • Syntax:
    • Product_stl=ini_work_file('WorkpieceModel', 'solidname').database_read(INI_Path_File)
• Polygon:
  enter a polygon solid in Z direction (for example: used for my stock creation from hexbar to round)
  • Syntax:
    • Polygon((comp),x_center, y_center, z_center, length, radius, number_sides, inscribed)
    • number_sides = number of polygon sides
    • inscribed = boolean = if the given radius is: read as inscribed, measured on flats (1) or measured on the points (0).
•  ThreadBox:
  Creates a box of "wiremess" (for example: used for my working area)
  • Syntax:
    • Polygon((comp),xmin, ymin, zmin, xmax, ymax, zmax, radius, sradius)
    • xyz min and max for your corners.
    • radius =  the radius of the ribs.
    • sradius = the radius of the sphers on the corners.
• Small aditions, icon, View_Ori and TextHeightButtons (to keep the screen small with to many model groups).
•  Made parallel the starting option.
•  Changed "show overlay" from radio button to check box
•  CylinderOriented, this function won't work if xystart and xyend are equal. i added some (brute force) logic to check and bypass the used matrix.

 Aciera thanks for providing this nice simulation tool!

I tried this out. Excellent job.
I did not if I move the origin the material stock does not move, even if I rebuild the material. Does this happen for you?

During all this progress we also setup my wife's shop with warm and cold water

and what once was my temporary home is now the shelter for our old sofa and her loom

all that was left was to get sone beer and cake

set up the benches 

and wait in the courtyard by the fire with the dog for the friend to arrive

then it was time for the lathe.

getting here under power and leveled was a bit more challenging. then there was another issue. In the old shop I could have a hoist on a roof beam to change the chucks... here not, so I needed another solution:

An old winch, one multifix mount and a pickup crane did the trick

 

followed by the battery powered shit

and the welding table 

then the first cnc machine was ready to get leveled and under power:

and for the first time since I started setting up this machine it got its two vices mounted:

so it can be used soon hopefully and also I can start working on fully integrate the 4th axis.

 

having the the wall ducts allow also to semi integrate the air lines

then it was time to set everything up beginning with the 3D Printers

manual machines

the there was really long time no progress, cause focus was on the house, which brings us to the point two months ago, where instead of going on our vacation we made a big leap with our shops.
Beginning by further insulating mine.

and finishing the walls

setting up first work benches and begin wiring the whole shop

this was the time where the house became uninhabitable an I moved into the shop

which showed that workbenches are great temporary kitchens:

 

the old barn windows were really drafty and I want the shop to be more usable in winter I installed additional modern windows. 

 after getting the breaker box in my house 

 I could setup the new boxes in the workshop