Search Results (Searched for: )
- fer662
@andrax are you on an XYYZ machine like your posted config suggests? can you respond regarding how the Ys sync up with the absolute encoder? The other thing i'm concerned about is if I should use homing mode 20 instead of 4 for Y, because otherwise the z pulse step becomes something that'll mess up your parallelism without you being able to adjust by adjusting the sensor triggers
- andrax
Yes, you're right,
CIA homing isn't really well documented yet.
In principle, it works like this:
The CIA-home function triggers the servos' internal homing routine and monitors the status. Once the servos report completion, CIA-home signals to LinuxCNC that homing is finished.
The drive error after homing is normal.
This happens when CIA-home hands control back to LinuxCNC.
Make sure the lowest feed rate is set; the axes will then synchronize without errors.
- rodw
-

- rodw
-

Did you try the revised instructions in the first post?The issue seems to be DKMS failing with the latest debian kernel. I couldn’t figure out how to uninstall the kernel but I was able to stop it from being installed on a new system. Before you do a
[/code]Code:sudo apt upgrade. stop any kernel update with [code]sudo apt-mark hold *6.12* basically wildcard the 6.12 string on both sides to prevent anything related to the kernel from being updated.
- Aciera
So if you wanted your parameter page to reflect changes coming from the gcode program you would need to insert the remap after every parameter assignment in the gcode.
Another way to expose parameter values is to send them to a hal pin:
'M68 E0 Q#500' will expose parameter value 500 to the hal pin 'motion.analog-out-00' which you can then connect to your gladevcp display.
Note that the M68 code would need to be called every time after the #500 parameter is changed in the gcode and every parameter will need its own analog pin.
You could create a custom G- or M-Code to handle assigning and exposing parameter values in a single line and/or use a filter script to search for parameter assignments and add the appropriate M68 code to expose it.
- stoobydale
- tommylight
-

forum.linuxcnc.org/show-your-stuff/38547...-5m-cnc-plasma-build
forum.linuxcnc.org/plasma-laser/35349-cn...lding-info-and-guide
And laptops are not usually preferred for running LinuxCNC due to inherent power saving features that cause latency issues.
Having said that, here are some that do work:
forum.linuxcnc.org/18-computer/54369-use...mesa-ethernet-boards
And some used and new PC's tested with LinuxCNC
forum.linuxcnc.org/18-computer/38838-har...ency-tests-used-pc-s
- stoobydale
New to the forum and new to cnc. I am building a CNC plasma cutting table based on plans from Homemade Madness however, I would like to use LinuxCNC instead of Mach3 as in the plan. I have not bought any of the motors or controllers yet so was hoping to get some advice before purchasing anything. I plan to use an old laptop for the install of Linux and LinuxCNC so am also looking for suggestions for the best version of Linux to use. Thanks in advance for any suggestions, help.
- Todd Zuercher
- SoloRev
- Todd Zuercher
- Aciera
- fer662
- This repo is the best one I found for both homecomp implementation and linuxCNC config for these servos github.com/nickstewartroc/linuxcnc-a6-servo , and it is a fork from the one mentioned by @andrax (though the files he posted are not from there or are modified at least). Only one thing from there didn't work for me which is the binding of the di pins to see their state, they didn't reflect the way they are setup there. This is how each servo looks and what worked for seeing the home switches change state ( see<pdoEntry idx="2040" subIdx="05" bitLen="16" halType="complex"
. Also, I initially had issues halcompiling this homecomp with the additional includes, it was giving me an error on some types, make sure the cloned linuxCNC repo is on the same tag as your installation and not on main.- Wire the home switch per page 26 of the manual. You need to tie either COM- or COM+ to your external PSU's negative output depending on the sensor type (NPN or PNP). I had tied COM- instead of COM+ for PNP and that wasn't working. Make sure DI3 flips when the sensor toggles before proceeding any further.<slave idx="3" type="generic" vid="0x00400000" pid="0x00000715" configPdos="true">
<dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="300000"/>
<watchdog divider="2498" intervals="1000" />
<sdoConfig idx="2004" subIdx="0a"><sdoDataRaw data="01 00"/></sdoConfig>
<syncManager idx="2" dir="out">
<pdo idx="1600">
<pdoEntry idx="6040" subIdx="00" bitLen="16" halPin="control-word" halType="u32" />
<pdoEntry idx="6060" subIdx="00" bitLen="8" halPin="control-mode" halType="s32" />
<pdoEntry idx="607A" subIdx="00" bitLen="32" halPin="target-position" halType="s32" />
<pdoEntry idx="60FF" subIdx="00" bitLen="32" halPin="target-velocity" halType="s32"/>
<pdoEntry idx="607C" subIdx="00" bitLen="32" halPin="home-offset" halType="s32"/>
<pdoEntry idx="6098" subIdx="00" bitLen="8" halPin="homing-method" halType="s32" />
<pdoEntry idx="6099" subIdx="01" bitLen="32" halPin="homing-high-velocity" halType="u32"/>
<pdoEntry idx="6099" subIdx="02" bitLen="32" halPin="homing-low-velocity" halType="u32"/>
<pdoEntry idx="609A" subIdx="00" bitLen="32" halPin="homing-acceleration" halType="u32"/>
</pdo>
</syncManager>
<syncManager idx="3" dir="in">
<pdo idx="1A00">
<pdoEntry idx="6041" subIdx="00" bitLen="16" halPin="status-word" halType="u32" />
<pdoEntry idx="6061" subIdx="00" bitLen="8" halPin="mode-display" halType="s32" />
<pdoEntry idx="6064" subIdx="00" bitLen="32" halPin="actual-position" halType="s32" />
<pdoEntry idx="606C" subIdx="00" bitLen="32" halPin="actual-velocity" halType="s32"/>
<pdoEntry idx="6077" subIdx="00" bitLen="16" halPin="actual-torque" halType="s32"/>
<pdoEntry idx="60FD" subIdx="00" bitLen="32" halPin="digital-inputs" halType="u32"/>
<pdoEntry idx="2040" subIdx="05" bitLen="16" halType="complex">
<complexEntry bitLen="1" halPin="di-1" halType="bit"/>
<complexEntry bitLen="1" halPin="di-2" halType="bit"/>
<complexEntry bitLen="1" halPin="di-3" halType="bit"/>
<complexEntry bitLen="1" halPin="di-4" halType="bit"/>
<complexEntry bitLen="1" halPin="di-5" halType="bit"/>
<complexEntry bitLen="11"/>
</pdoEntry>
</pdo>
</syncManager>
</slave>
- Depending on whether your sensor is NC or NO, you need to change your home switch between active low and active high, documentation for this is in page 209. (<sdoConfig idx="2004" subIdx="0a"><sdoDataRaw data="01 00"/></sdoConfig> in my config for NC switch). Also on page 209 is the function selection for DI3. It's set correctly by default, but one of my drives had it wrong and i presume this was the result of debugging changes made via dcConf entries that got removed. Check that all yours drives have it on the correct setting which is 5. You could technically use any of the DI pins that have function selection as the home switch changing stuff around this PDO. By this time the sensor pin should light up in halshow when triggered no matter whether the sensor is NO or NC.
- At this point it should be possible (though i haven't tested, i did have it working with the pins wired to the beckoff inputs though) to configure regular homing using the drive pins as input if you wished to test it out for sanity checking.
- Assuming that works or you skip it, copy the relevant bits of the hal in the referenced repo. I didn't have to change anything there since i dumped my XML (which was already very close but had slightly different property names) so i could just copypaste as it was.
- I used homing mode 4 like @Andrax but that might not be right for you. On Page 74 there's ample documentation for how each home mode works.
- When trying things out you might use low speeds for the 2 speeds involved in homing. Beware homing has a timeout that defaults to 60 seconds on the servo config. Homecomp doesn't catch this timeout and gets stuck forever, leading you to have to close linuxCNC and power cycle the drives (Page 215).
- Presumably once you're happy you'd comment the homing stuff and add HOME_ABSOLUTE_ENCODER to the joints like the initial post suggests.
I hope this helps someone, and please let me know if your know what the amplifier faults i'm getting after homing might be. This is my first time using linuxCNC. My config is attached for whoever finds it useful or can help me with the little bit i think i have left to fix.
- Aciera
2. This method of reading the initial parameter values is nonsense as there is no access to the parameter values from the status channel:
see linuxcnc.org/docs/html/config/python-interface.html for information on the 'settings' attribute.
Some thoughts on this:
a. The parameter range you are trying to read is volatile so they will all be Zero on start up. See linuxcnc.org/docs/stable/html/gcode/over...:overview-parameters
b. The only way to get the current value of any parameter is to read the value through an MDI command and grab the response.
c. Because of (b) there is no way I know of to actually query the state of a parameter while a gcode program is executing. Which implies that you would need to have something like a 'Refresh' button to read the current values of those parameters if they were changed by the execution of a gcode program.
- rodw
-

There was some talk of publishing a new 2.9.x version to fix some bugs. If that is the case, I will send in a PR to update the repos in the installer based on the link above.