Search Results (Searched for: )
- spumco
- spumco
Yesterday 02:43
REMAP: gang lathe tool orientation was created by spumco
REMAP: gang lathe tool orientation
Category: Advanced Configuration
Learning how to actually operate the lathe I built, and I've confused myself over tool orientation.
Gang-tool lathe, with front and back tools. Defined in INI as a back tool lathe, but that can change if needed.
I use Fusion for CAM, and the standard LCNC post for fusion. The post handles front/back tool orientation by setting the 'turret' value in the F360 tool library to 103 or 104. When the post sees a '103' for the turret, it outputs all X-moves with negative values. Opposite for '104'.
While this results in appropriate tool motion, the LCNC backplot is wrong, kinda. The toolpaths are appropriately displayed as negative X (below centerline), but the tool tip indicator is approaching across the centerline - looks kinda crashy.
Having researched the forum a while back about gang-tool lathes, I found the 'trick' about using G10 to rotate the WCS 180 degrees around Z for back tools. So I've got a couple M-codes to do just that - flip back and forth between back and front tool views.
Caught me off guard the first time I flipped the X axis and jogs were backwards. I somehow thought it was just the display/backplot that rotated...
But that got me thinking about the point of this long-winded post. Can I use the lathe tool orientation value (parameter #5413) to drive the M-code WCS flip during a tool change? And leave all tools as 'front turret' in F360 so the post only outputs X positive numbers?
I've got a lathe-fanucy test config on deck (remap T) for testing. Maybe add a conditional check for the value of #5413? Something like:
Anyone see any holes in my theory or suggestions for improvement?
Gang-tool lathe, with front and back tools. Defined in INI as a back tool lathe, but that can change if needed.
I use Fusion for CAM, and the standard LCNC post for fusion. The post handles front/back tool orientation by setting the 'turret' value in the F360 tool library to 103 or 104. When the post sees a '103' for the turret, it outputs all X-moves with negative values. Opposite for '104'.
While this results in appropriate tool motion, the LCNC backplot is wrong, kinda. The toolpaths are appropriately displayed as negative X (below centerline), but the tool tip indicator is approaching across the centerline - looks kinda crashy.
Having researched the forum a while back about gang-tool lathes, I found the 'trick' about using G10 to rotate the WCS 180 degrees around Z for back tools. So I've got a couple M-codes to do just that - flip back and forth between back and front tool views.
Caught me off guard the first time I flipped the X axis and jogs were backwards. I somehow thought it was just the display/backplot that rotated...
But that got me thinking about the point of this long-winded post. Can I use the lathe tool orientation value (parameter #5413) to drive the M-code WCS flip during a tool change? And leave all tools as 'front turret' in F360 so the post only outputs X positive numbers?
I've got a lathe-fanucy test config on deck (remap T) for testing. Maybe add a conditional check for the value of #5413? Something like:
O<toolchange> sub
(debug, Tool requested = #<tool>)
#<wear> = [10000 + FIX[ #<tool> / 100]]
#<tool> = [#<tool> MOD 100]
M6 T#<tool>
G43 H#<tool>
O100 IF [#<wear> GT 10000]
G43.2 H#<wear>
O100 ENDIF
#<pocket> = #<tool>
(NEW WCS FLIP HERE - M268=FRONT, M269=BACK)
O101 IF [#5413 LT 1]
(abort, tool missing orientation value)
O101 ELSEIF [#5413 EQ 1]
M268
O101 ELSEIF [#5413 EQ 2]
M268
O101 ELSEIF [#5413 EQ 6]
M268
O101 ELSE
M269
O101 ENDIF
(END WCS FLIP HERE)
(debug, tool = #<tool> wear = #<wear>)
O<toolchange> endsub [0]Anyone see any holes in my theory or suggestions for improvement?
- bedouno
- bedouno
Yesterday 01:03
Replied by bedouno on topic HAL component for tangential knife
HAL component for tangential knife
Category: HAL
DEAR Sir, it is great work and i hope to learn alot of you , that was very deep in the CNC FOUNDATION, I am now in need to use my machine and the level of mach3 is very suffecient to me , so what do you recommend to achieve this level now and i hope to join your effort of your project that i hope to learn much of you , thank you sir
- grandixximo
Yesterday 00:39 - Yesterday 02:13
Replied by grandixximo on topic Ethercat random jitter fix
Ethercat random jitter fix
Category: EtherCAT
Demystifying syncToRefClock and refClockSyncCycles
syncToRefClock="true" means the master syncs to the slaves, adjusting its period every cycle to track the DC reference clock (PLL/bang-bang mode).
syncToRefClock="false" means the slaves sync to the master. refClockSyncCycles then controls how often (every N cycles) the slaves perform a sync adjustment.
refClockSyncCycles="-1" (any negative number) means master syncs to slaves, identical to syncToRefClock="true". The magnitude does not matter.
So all four combinations you tested:
refClockSyncCycles="1" syncToRefClock="true"
refClockSyncCycles="5" syncToRefClock="true"
refClockSyncCycles="1000" syncToRefClock="true"
refClockSyncCycles="-1" syncToRefClock="true"
are completely identical. When syncToRefClock="true", the slaves are not in a mode where they sync to the master, so refClockSyncCycles is simply ignored.
The combination refClockSyncCycles="-1" with syncToRefClock="false" is a contradiction and will be treated as invalid in a future version.
Why you heard noise with syncToRefClock="true" and sync0Shift="0"
This is expected and correct behaviour. With sync0Shift="0", SYNC0 fires exactly at t=0, right as the cyclic frame is arriving. The slave latches output data at the same instant it is being written, creating a race condition every cycle. The grinding noise is the mechanical result.
The fix is not to disable syncToRefClock. Set a proper shift:
<dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="300000"/>
300000 to 500000 ns on a 1ms cycle is a reasonable starting point. Try that with syncToRefClock="true" and the noise should go away.
If you think sync0Shift="0" always worked for you
It did not work correctly, it appeared to work. The race condition was present but your hardware was consistently winning it by luck. The code now behaves strictly per ETG.1020. If it seemed to work before, it was not according to the standard. Update your configuration.
To help investigate the OP regression, can you run the following and paste the output?
dpkg -l | grep ethercat
Do this on the system with the 1.5.2 that OP's quickly please
maybe we get more than just 1.5.2 we can get some build reference, and I can look at the code, the 1.5.2 I found is identical in OP time as 1.6.8
syncToRefClock="true" means the master syncs to the slaves, adjusting its period every cycle to track the DC reference clock (PLL/bang-bang mode).
syncToRefClock="false" means the slaves sync to the master. refClockSyncCycles then controls how often (every N cycles) the slaves perform a sync adjustment.
refClockSyncCycles="-1" (any negative number) means master syncs to slaves, identical to syncToRefClock="true". The magnitude does not matter.
So all four combinations you tested:
refClockSyncCycles="1" syncToRefClock="true"
refClockSyncCycles="5" syncToRefClock="true"
refClockSyncCycles="1000" syncToRefClock="true"
refClockSyncCycles="-1" syncToRefClock="true"
are completely identical. When syncToRefClock="true", the slaves are not in a mode where they sync to the master, so refClockSyncCycles is simply ignored.
The combination refClockSyncCycles="-1" with syncToRefClock="false" is a contradiction and will be treated as invalid in a future version.
Why you heard noise with syncToRefClock="true" and sync0Shift="0"
This is expected and correct behaviour. With sync0Shift="0", SYNC0 fires exactly at t=0, right as the cyclic frame is arriving. The slave latches output data at the same instant it is being written, creating a race condition every cycle. The grinding noise is the mechanical result.
The fix is not to disable syncToRefClock. Set a proper shift:
<dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="300000"/>
300000 to 500000 ns on a 1ms cycle is a reasonable starting point. Try that with syncToRefClock="true" and the noise should go away.
If you think sync0Shift="0" always worked for you
It did not work correctly, it appeared to work. The race condition was present but your hardware was consistently winning it by luck. The code now behaves strictly per ETG.1020. If it seemed to work before, it was not according to the standard. Update your configuration.
To help investigate the OP regression, can you run the following and paste the output?
dpkg -l | grep ethercat
Do this on the system with the 1.5.2 that OP's quickly please
maybe we get more than just 1.5.2 we can get some build reference, and I can look at the code, the 1.5.2 I found is identical in OP time as 1.6.8
- tommylight
Yesterday 22:16
Replied by tommylight on topic HAL component for tangential knife
HAL component for tangential knife
Category: HAL
Done, thank you.@Tommy, add FOR TANGENTAL KNIFE to the title
- rodw
Yesterday 21:36
Replied by rodw on topic HAL component for tangential knife
HAL component for tangential knife
Category: HAL
@Tommy, add FOR TANGENTAL KNIFE to the title
@bedouno, Linuxcnc's architecture is complex and described in the docs here
linuxcnc.org/docs/devel/html/code/code-notes.html
The problem to set the tangential heading is that the geometry is known by the gcode but once the gcode is tokenised into a buffer, the gcode (and geometry) is thrown away so motion is just left with way points and segments. Furthermore, this gcode tokenisation is buffered so the interpreter can be many segments ahead of the motion parameters at run time.The intent of state tags was to "tag" each of these motion segments with the interpreter state so certain information was known by motion but it is not exposed in a useful way. (It was originally for GUI's).
The purpose of my code was to extend the state tags mechanism to include the radius and tangential heading and publish the available tags to a set of pins so the data can be used by anyone.
You can do some stuff in a hal component by saving the lastX and lastY positions (axis.L.pos-cmd) and the current axis.x.pos-cmd and axis.y.pos-cmd. motion.motion-type tells you if you are on an arc or a linear segment. Now you can do some trig calculations. If its linear you just need to calculate the slope of the line (angle) and you have the heading. If its an arc, you can calculate the radius, arc and then the tangent which is your heading. I tried this and never got reliable results.
Ref: linuxcnc.org/docs/devel/html/man/man9/motion.9.html
Regardless of what AI thinks, there isn't a method to inject into the motion planner. Perhaps you can develop a kinematic model of the tangential knife. linuxcnc.org/docs/devel/html/motion/kinematics.html
But I think the correct method which AI won't know anything about is to work with state tags.
My thought was that there would be a component that took the heading and set the A axis angle with it.
Yesterday, I made a start on merging the current 2.10 master branch into my 6 year old arc-radius branch but I have not committed it back to GitHub. github.com/rodw-au/linuxcnc/tree/arc-radius
There are 7 files that need manual intervention because of changes to the code base. I'm on my second attempt.....
@bedouno, Linuxcnc's architecture is complex and described in the docs here
linuxcnc.org/docs/devel/html/code/code-notes.html
The problem to set the tangential heading is that the geometry is known by the gcode but once the gcode is tokenised into a buffer, the gcode (and geometry) is thrown away so motion is just left with way points and segments. Furthermore, this gcode tokenisation is buffered so the interpreter can be many segments ahead of the motion parameters at run time.The intent of state tags was to "tag" each of these motion segments with the interpreter state so certain information was known by motion but it is not exposed in a useful way. (It was originally for GUI's).
The purpose of my code was to extend the state tags mechanism to include the radius and tangential heading and publish the available tags to a set of pins so the data can be used by anyone.
You can do some stuff in a hal component by saving the lastX and lastY positions (axis.L.pos-cmd) and the current axis.x.pos-cmd and axis.y.pos-cmd. motion.motion-type tells you if you are on an arc or a linear segment. Now you can do some trig calculations. If its linear you just need to calculate the slope of the line (angle) and you have the heading. If its an arc, you can calculate the radius, arc and then the tangent which is your heading. I tried this and never got reliable results.
Ref: linuxcnc.org/docs/devel/html/man/man9/motion.9.html
Regardless of what AI thinks, there isn't a method to inject into the motion planner. Perhaps you can develop a kinematic model of the tangential knife. linuxcnc.org/docs/devel/html/motion/kinematics.html
But I think the correct method which AI won't know anything about is to work with state tags.
My thought was that there would be a component that took the heading and set the A axis angle with it.
Yesterday, I made a start on merging the current 2.10 master branch into my 6 year old arc-radius branch but I have not committed it back to GitHub. github.com/rodw-au/linuxcnc/tree/arc-radius
There are 7 files that need manual intervention because of changes to the code base. I'm on my second attempt.....
- tommylight
Yesterday 21:32
You would need a Mesa 7i95T board as it has step/dir outputs and encoder inputs so the glass scales would be wired to those encoder inputs.
There are other combinations of Mesa boards, like 7i96S with 7i85 etc, but first make sure the glass scales can be wired to normal incremental encoder inputs.
Replied by tommylight on topic SIEG SX3.5Z Drivers EtherCAT A6 Steppers
SIEG SX3.5Z Drivers EtherCAT A6 Steppers
Category: Driver Boards
No, but you can use them with LinuxCNC and leave the drives as they are.... i bought the mill with glas scales and i like to implement them in the driver if possible?
You would need a Mesa 7i95T board as it has step/dir outputs and encoder inputs so the glass scales would be wired to those encoder inputs.
There are other combinations of Mesa boards, like 7i96S with 7i85 etc, but first make sure the glass scales can be wired to normal incremental encoder inputs.
- Hakan
- Hakan
Yesterday 19:56
Replied by Hakan on topic SIEG SX3.5Z Drivers EtherCAT A6 Steppers
SIEG SX3.5Z Drivers EtherCAT A6 Steppers
Category: Driver Boards
You can use glass scales instead of the servo's encoder. BUT.
The driver must interface to the glass scales. And that is most likely the problem.
I'm guessing the glass scales uses incremental quadrature signal.
In the product listing it's mentioned 17-bit absolute encoder.
That's not the same and will not work.
You must check the capabilities of the drive, if it can accept incremental quadrature signal.
If it can do that, there is a big chance it will work.
Summary:
- Check interface of the glass scales
- Check that the drive can use that.
The driver must interface to the glass scales. And that is most likely the problem.
I'm guessing the glass scales uses incremental quadrature signal.
In the product listing it's mentioned 17-bit absolute encoder.
That's not the same and will not work.
You must check the capabilities of the drive, if it can accept incremental quadrature signal.
If it can do that, there is a big chance it will work.
Summary:
- Check interface of the glass scales
- Check that the drive can use that.
- juan13372k
- juan13372k
Yesterday 19:05
Replied by juan13372k on topic SIEG SX3.5Z Drivers EtherCAT A6 Steppers
SIEG SX3.5Z Drivers EtherCAT A6 Steppers
Category: Driver Boards
nobody 
- tommylight
Yesterday 18:46
Replied by tommylight on topic HAL component for tangential knife
HAL component for tangential knife
Category: HAL
What should the tittle of this topic be?
As is seems left in half.
As is seems left in half.
- Pudding1960
- Pudding1960
Yesterday 18:28
Probleme mit G Code... was created by Pudding1960
Probleme mit G Code...
Category: General LinuxCNC Questions
Hallo Zusammen ! Da bin ich mal wieder mit einem oder besser mehreren Problemen... Mittlerweile weiß ich nicht mehr weiter. Meine Fräse spinnt ja des öfteren,da habe ich mich schon daran gewöhnt,einfach am nächsten Tag wieder Versuchen ,dann ging es meistens wieder. Fehlermeldungen wie" Radius to end of arc differs from Radius to start und ähnliches bin ich ja schon gewöhnt. Da half oft einfach einen anderen G Code zu Laden,Starten und gleich wieder Stoppen,dann den Ursprünglichen Code wieder Laden und dann ging es . Jetzt Kommt aber die Fehlermeldung,dass die Fehlermeldung" Bewegung Linear in Zeile 19 würde Anschlag der Achse 1 Überschreiten! Das Dumme ist nur,dass das Werkstück 40mm Durchmesser hat und ich nach jeder Seite 250mm Weg über habe. Jeden Start quittiert die Maschine mit einem sofortigen Stopp. Ich habe für das Werkstück 2 G Codes,einmal für eine 3,17mm Fräser und einmal für einen 2mm Fräser zum Schlichten. Der G Code für den 3,17mm Fräser läuft ohne Probleme,der für den 2mm Fräser nicht. Ich habe schon ein neues Setup Probiert,für jeden Arbeitsschritt einen eigen G-Code erstellt,alles ohne Erfolg. Meine Steuerung ist eine Mesa 7i76e ,an allen Achsen Closed Loop. Das Nonplusultra wäre jemand im Raum Laa an der Thaya in Niederösterreich,der sich das mal in Natura gegen Bezahlung natürlich anschauen könnte. Ich bin mit meinem Latein Mittlerweile am Ende. Ein neues Bedienpult neuem Steuerrechner(I 5) steht auch schon in den Startlöchern,da bin ich auch noch am Tüfteln wegen Werkzeuglängen vermessung und Antastfunktion ect. G-Code häng ich mal an,vielleicht findet wer den Fehler,ich werde nicht daraus Schlau. Mit Dank im Voraus !
- Hakan
- Hakan
Yesterday 18:22 - Yesterday 18:23
Replied by Hakan on topic Ethercat random jitter fix
Ethercat random jitter fix
Category: EtherCAT
Scott thought so too forum.linuxcnc.org/ethercat/52200-defaul...a-402-devices#297315
One should really have a look in the servo's ESI file and see what it says.
One should really have a look in the servo's ESI file and see what it says.
- endian
Yesterday 18:12
I have hardware which runs at 250us and generic driver was not capable therefore I searched for other way of grinding avoiding with higher value of assign ... else with native chip driver is 0x0300 good enough
Replied by endian on topic Ethercat random jitter fix
Ethercat random jitter fix
Category: EtherCAT
what help me during the grinding noise was reinstall driver to chip native or dcConf assignActivate = "300" edit to something as dcConf assignActivate = "730" ... then generic driver works well ...xml on debian trixie
i have test refClockSyncCycles = -1 , but problem is the same
Warning: Spoiler!
<masters>
<master idx="0" appTimePeriod="1000000" refClockSyncCycles="1" syncToRefClock="true">
<slave idx="0" type="generic" vid="0000022b" pid="0531ec01" configPdos="true">
<sdoConfig idx="3103" subIdx="08">
<sdoDataRaw data="16"/>
</sdoConfig>
<sdoConfig idx="3104" subIdx="08">
<sdoDataRaw data="16"/>
</sdoConfig>
<sdoConfig idx="3103" subIdx="09">
<sdoDataRaw data="03"/>
</sdoConfig>
<sdoConfig idx="3104" subIdx="09">
<sdoDataRaw data="01"/>
</sdoConfig>
<syncManager idx="0" dir="out"></syncManager>
<syncManager idx="1" dir="in"></syncManager>
<syncManager idx="2" dir="out">
<pdo idx="1600">
<pdoEntry idx="7001" subIdx="01" bitLen="8" halPin="out_veloci" halType="bit"/>
<pdoEntry idx="7002" subIdx="01" bitLen="16" halPin="ao0" halType="float" scale="2765"/>
<pdoEntry idx="7002" subIdx="02" bitLen="16" halPin="ao1" halType="float" scale="2765"/>
<pdoEntry idx="7003" subIdx="01" bitLen="32" halPin="comparation_value" halType="float" scale="1"/>
<pdoEntry idx="7003" subIdx="02" bitLen="32" halPin="setvalue" halType="float" scale="1"/>
<pdoEntry idx="7003" subIdx="03" bitLen="16" halPin="control_word" halType="bit"/>
<pdoEntry idx="7004" subIdx="01" bitLen="32" halPin="comparation_valuev" halType="float" scale="1"/>
<pdoEntry idx="7004" subIdx="02" bitLen="32" halPin="setvaluev" halType="float" scale="1"/>
<pdoEntry idx="7004" subIdx="03" bitLen="16" halPin="control_wordv" halType="bit"/>
</pdo>
</syncManager>
<syncManager idx="3" dir="in">
<pdo idx="1a00">
<pdoEntry idx="6000" subIdx="01" bitLen="8" halPin="in_veloci" halType="bit"/>
<pdoEntry idx="6003" subIdx="01" bitLen="32" halPin="counter_value" halType="float" scale="1"/>
<pdoEntry idx="6003" subIdx="02" bitLen="16" halPin="counter_status" halType="bit"/>
<pdoEntry idx="6003" subIdx="03" bitLen="16" halPin="microsecond" halType="S32"/>
<pdoEntry idx="6004" subIdx="01" bitLen="32" halPin="counter_valuev" halType="float" scale="1"/>
<pdoEntry idx="6004" subIdx="02" bitLen="16" halPin="counter_statusv" halType="bit"/>
<pdoEntry idx="6004" subIdx="03" bitLen="16" halPin="microsecondv" halType="S32"/>
</pdo>
</syncManager>
<dcConf assignActivate = "300" sync0Cycle = "*1" sync0Shift = "0" />
<watchdog divider="2498" intervals="1000"/>
</slave>
<!-- INIZIO PARAMETRI ASSE X -->
<slave idx="1" type="generic" vid="850104" pid="01030507" configPdos="true">
<syncManager idx="0" dir="out"></syncManager>
<syncManager idx="1" dir="in"></syncManager>
<syncManager idx="2" dir="out">
<pdo idx="1600">
<pdoEntry idx="6040" subIdx="00" bitLen="16" halPin="drivecontrol" halType="bit"/>
<pdoEntry idx="6060" subIdx="00" bitLen="8" halPin="opmode" halType="u32"/>
<!--PARAMETRO POSCOMAND IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="607A" subIdx="00" bitLen="32" halPin="poscommand" halType="float" scale="838860.7"/>
<pdoEntry idx="6098" subIdx="00" bitLen="8" halPin="homemode" halType="u32"/>
<!--PARAMETRO HOMESPPED1 IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="6099" subIdx="01" bitLen="32" halPin="homespeed1" halType="float" scale="838860.7"/>
<!--PARAMETRO HOMESPPED2 IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="6099" subIdx="02" bitLen="32" halPin="homespeed2" halType="float" scale="838860.7"/>
<!--PARAMETRO HOMEACC IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="609A" subIdx="00" bitLen="32" halPin="homeacc" halType="float" scale="838860.7"/>
<!--PARAMETRO HOMEOFFSET IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="607C" subIdx="00" bitLen="32" halPin="homeoffset" halType="float" scale="838860.7"/>
</pdo>
</syncManager>
<syncManager idx="3" dir="in">
<pdo idx="1a00">
<pdoEntry idx="6041" subIdx="00" bitLen="16" halPin="drivestatus" halType="bit"/>
<pdoEntry idx="6063" subIdx="00" bitLen="32" halPin="enccounts" halType="s32"/>
<!--PARAMETRO POS IN SCALE SCRIVERE X/8388607 DOVE X SONO MM A GIRO MOTORE ESEMP: 10/8388607/= 0.0000078125 -->
<pdoEntry idx="6064" subIdx="00" bitLen="32" halPin="pos" halType="float" scale="0.0000011920930376"/>
<pdoEntry idx="6077" subIdx="00" bitLen="16" halPin="torque%" halType="float" scale="0.1"/>
<pdoEntry idx="606C" subIdx="00" bitLen="32" halPin="velmotore" halType="float" scale="0.00007"/>
<pdoEntry idx="603F" subIdx="00" bitLen="16" halPin="allarm" halType="u32"/>
</pdo>
</syncManager>
<dcConf assignActivate = "300" sync0Cycle = "*1" sync0Shift = "0" />
<watchdog divider="2498" intervals="1000"/>
</slave>
<!-- INIZIO PARAMETRI ASSE Y -->
<slave idx="2" type="generic" vid="850104" pid="01030507" configPdos="true">
<syncManager idx="0" dir="out"></syncManager>
<syncManager idx="1" dir="in"></syncManager>
<syncManager idx="2" dir="out">
<pdo idx="1600">
<pdoEntry idx="6040" subIdx="00" bitLen="16" halPin="drivecontrol" halType="bit"/>
<pdoEntry idx="6060" subIdx="00" bitLen="8" halPin="opmode" halType="u32"/>
<!--PARAMETRO POSCOMAND IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="607A" subIdx="00" bitLen="32" halPin="poscommand" halType="float" scale="838860.7"/>
<pdoEntry idx="6098" subIdx="00" bitLen="8" halPin="homemode" halType="u32"/>
<!--PARAMETRO HOMESPPED1 IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="6099" subIdx="01" bitLen="32" halPin="homespeed1" halType="float" scale="838860.7"/>
<!--PARAMETRO HOMESPPED2 IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="6099" subIdx="02" bitLen="32" halPin="homespeed2" halType="float" scale="838860.7"/>
<!--PARAMETRO HOMEACC IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="609A" subIdx="00" bitLen="32" halPin="homeacc" halType="float" scale="838860.7"/>
<!--PARAMETRO HOMEOFFSET IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="607C" subIdx="00" bitLen="32" halPin="homeoffset" halType="float" scale="838860.7"/>
</pdo>
</syncManager>
<syncManager idx="3" dir="in">
<pdo idx="1a00">
<pdoEntry idx="6041" subIdx="00" bitLen="16" halPin="drivestatus" halType="bit"/>
<pdoEntry idx="6063" subIdx="00" bitLen="32" halPin="enccounts" halType="s32"/>
<!--PARAMETRO POS IN SCALE SCRIVERE X/8388607 DOVE X SONO MM A GIRO MOTORE ESEMP: 10/8388607/= 0.0000011920930376 -->
<pdoEntry idx="6064" subIdx="00" bitLen="32" halPin="pos" halType="float" scale="0.0000011920930376"/>
<pdoEntry idx="6077" subIdx="00" bitLen="16" halPin="torque%" halType="float" scale="0.1"/>
<pdoEntry idx="606C" subIdx="00" bitLen="32" halPin="velmotore" halType="float" scale="0.00007"/>
<pdoEntry idx="603F" subIdx="00" bitLen="16" halPin="allarm" halType="u32"/>
</pdo>
</syncManager>
<dcConf assignActivate = "300" sync0Cycle = "*1" sync0Shift = "0" />
<watchdog divider="2498" intervals="1000"/>
</slave>
<!-- INIZIO PARAMETRI ASSE Z -->
<slave idx="3" type="generic" vid="850104" pid="01030507" configPdos="true">
<syncManager idx="0" dir="out"></syncManager>
<syncManager idx="1" dir="in"></syncManager>
<syncManager idx="2" dir="out">
<pdo idx="1600">
<pdoEntry idx="6040" subIdx="00" bitLen="16" halPin="drivecontrol" halType="bit"/>
<pdoEntry idx="6060" subIdx="00" bitLen="8" halPin="opmode" halType="u32"/>
<!--PARAMETRO POSCOMAND IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="607A" subIdx="00" bitLen="32" halPin="poscommand" halType="float" scale="838860.7"/>
<pdoEntry idx="6098" subIdx="00" bitLen="8" halPin="homemode" halType="u32"/>
<!--PARAMETRO HOMESPPED1 IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="6099" subIdx="01" bitLen="32" halPin="homespeed1" halType="float" scale="838860.7"/>
<!--PARAMETRO HOMESPPED2 IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="6099" subIdx="02" bitLen="32" halPin="homespeed2" halType="float" scale="838860.7"/>
<!--PARAMETRO HOMEACC IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="609A" subIdx="00" bitLen="32" halPin="homeacc" halType="float" scale="838860.7"/>
<!--PARAMETRO HOMEOFFSET IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="607C" subIdx="00" bitLen="32" halPin="homeoffset" halType="float" scale="838860.7"/>
</pdo>
</syncManager>
<syncManager idx="3" dir="in">
<pdo idx="1a00">
<pdoEntry idx="6041" subIdx="00" bitLen="16" halPin="drivestatus" halType="bit"/>
<pdoEntry idx="6063" subIdx="00" bitLen="32" halPin="enccounts" halType="s32"/>
<!--PARAMETRO POS IN SCALE SCRIVERE X/8388607 DOVE X SONO MM A GIRO MOTORE ESEMP: 10/8388607/= 0.0000011920930376 -->
<pdoEntry idx="6064" subIdx="00" bitLen="32" halPin="pos" halType="float" scale="0.0000011920930376"/>
<pdoEntry idx="6077" subIdx="00" bitLen="16" halPin="torque%" halType="float" scale="0.1"/>
<pdoEntry idx="606C" subIdx="00" bitLen="32" halPin="velmotore" halType="float" scale="0.00007"/>
<pdoEntry idx="603F" subIdx="00" bitLen="16" halPin="allarm" halType="u32"/>
</pdo>
</syncManager>
<dcConf assignActivate = "300" sync0Cycle = "*1" sync0Shift = "0" />
<watchdog divider="2498" intervals="1000"/>
</slave>
<!-- INIZIO PARAMETRI SP -->
<slave idx="4" type="generic" vid="01dd" pid="10400140" configPdos="true">
<syncManager idx="0" dir="out"></syncManager>
<syncManager idx="1" dir="in"></syncManager>
<syncManager idx="2" dir="out">
<pdo idx="1600">
<pdoEntry idx="6040" subIdx="00" bitLen="16" halPin="drivecontrol" halType="bit"/>
<pdoEntry idx="6042" subIdx="00" bitLen="16" halPin="cmdvel" halType="float"/>
<pdoEntry idx="6060" subIdx="00" bitLen="8" halPin="opmode" halType="u32"/>
</pdo>
</syncManager>
<syncManager idx="3" dir="in">
<pdo idx="1a00">
<pdoEntry idx="6041" subIdx="00" bitLen="16" halPin="drivestatus" halType="bit"/>
<pdoEntry idx="6077" subIdx="00" bitLen="16" halPin="torque%" halType="float" scale="0.1"/>
<pdoEntry idx="603F" subIdx="00" bitLen="16" halPin="allarm" halType="u32"/>
</pdo>
</syncManager>
<dcConf assignActivate = "300" sync0Cycle = "*1" sync0Shift = "0" />
<watchdog divider="2498" intervals="1000"/>
</slave>
<!-- INIZIO PARAMETRI ASSE A -->
<slave idx="5" type="generic" vid="850104" pid="01030507" configPdos="true">
<syncManager idx="0" dir="out"></syncManager>
<syncManager idx="1" dir="in"></syncManager>
<syncManager idx="2" dir="out">
<pdo idx="1600">
<pdoEntry idx="6040" subIdx="00" bitLen="16" halPin="drivecontrol" halType="bit"/>
<pdoEntry idx="6060" subIdx="00" bitLen="8" halPin="opmode" halType="u32"/>
<!--PARAMETRO POSCOMAND IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="607A" subIdx="00" bitLen="32" halPin="poscommand" halType="float" scale="838860.7"/>
<pdoEntry idx="6098" subIdx="00" bitLen="8" halPin="homemode" halType="u32"/>
<!--PARAMETRO HOMESPPED1 IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="6099" subIdx="01" bitLen="32" halPin="homespeed1" halType="float" scale="838860.7"/>
<!--PARAMETRO HOMESPPED2 IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="6099" subIdx="02" bitLen="32" halPin="homespeed2" halType="float" scale="838860.7"/>
<!--PARAMETRO HOMEACC IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="609A" subIdx="00" bitLen="32" halPin="homeacc" halType="float" scale="838860.7"/>
<!--PARAMETRO HOMEOFFSET IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="607C" subIdx="00" bitLen="32" halPin="homeoffset" halType="float" scale="838860.7"/>
</pdo>
</syncManager>
<syncManager idx="3" dir="in">
<pdo idx="1a00">
<pdoEntry idx="6041" subIdx="00" bitLen="16" halPin="drivestatus" halType="bit"/>
<pdoEntry idx="6063" subIdx="00" bitLen="32" halPin="enccounts" halType="s32"/>
<!--PARAMETRO POS IN SCALE SCRIVERE X/8388607 DOVE X SONO MM A GIRO MOTORE ESEMP: 10/8388607/= 0.0000011920930376 -->
<pdoEntry idx="6064" subIdx="00" bitLen="32" halPin="pos" halType="float" scale="0.0000011920930376"/>
<pdoEntry idx="6077" subIdx="00" bitLen="16" halPin="torque%" halType="float" scale="0.1"/>
<pdoEntry idx="606C" subIdx="00" bitLen="32" halPin="velmotore" halType="float" scale="0.00007"/>
<pdoEntry idx="603F" subIdx="00" bitLen="16" halPin="allarm" halType="u32"/>
</pdo>
</syncManager>
<dcConf assignActivate = "300" sync0Cycle = "*1" sync0Shift = "0" />
<watchdog divider="2498" intervals="1000"/>
</slave>
<!-- INIZIO PARAMETRI ASSE B -->
<slave idx="6" type="generic" vid="850104" pid="01030507" configPdos="true">
<syncManager idx="0" dir="out"></syncManager>
<syncManager idx="1" dir="in"></syncManager>
<syncManager idx="2" dir="out">
<pdo idx="1600">
<pdoEntry idx="6040" subIdx="00" bitLen="16" halPin="drivecontrol" halType="bit"/>
<pdoEntry idx="6060" subIdx="00" bitLen="8" halPin="opmode" halType="u32"/>
<!--PARAMETRO POSCOMAND IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="607A" subIdx="00" bitLen="32" halPin="poscommand" halType="float" scale="838860.7"/>
<pdoEntry idx="6098" subIdx="00" bitLen="8" halPin="homemode" halType="u32"/>
<!--PARAMETRO HOMESPPED1 IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="6099" subIdx="01" bitLen="32" halPin="homespeed1" halType="float" scale="838860.7"/>
<!--PARAMETRO HOMESPPED2 IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="6099" subIdx="02" bitLen="32" halPin="homespeed2" halType="float" scale="838860.7"/>
<!--PARAMETRO HOMEACC IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="609A" subIdx="00" bitLen="32" halPin="homeacc" halType="float" scale="838860.7"/>
<!--PARAMETRO HOMEOFFSET IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="607C" subIdx="00" bitLen="32" halPin="homeoffset" halType="float" scale="838860.7"/>
</pdo>
</syncManager>
<syncManager idx="3" dir="in">
<pdo idx="1a00">
<pdoEntry idx="6041" subIdx="00" bitLen="16" halPin="drivestatus" halType="bit"/>
<pdoEntry idx="6063" subIdx="00" bitLen="32" halPin="enccounts" halType="s32"/>
<!--PARAMETRO POS IN SCALE SCRIVERE X/8388607 DOVE X SONO MM A GIRO MOTORE ESEMP: 10/8388607/= 0.0000011920930376 -->
<pdoEntry idx="6064" subIdx="00" bitLen="32" halPin="pos" halType="float" scale="0.0000011920930376"/>
<pdoEntry idx="6077" subIdx="00" bitLen="16" halPin="torque%" halType="float" scale="0.1"/>
<pdoEntry idx="606C" subIdx="00" bitLen="32" halPin="velmotore" halType="float" scale="0.00007"/>
<pdoEntry idx="603F" subIdx="00" bitLen="16" halPin="allarm" halType="u32"/>
</pdo>
</syncManager>
<dcConf assignActivate = "300" sync0Cycle = "*1" sync0Shift = "0" />
<watchdog divider="2498" intervals="1000"/>
</slave>
<!-- INIZIO PARAMETRI ASSE C -->
<slave idx="7" type="generic" vid="850104" pid="01030507" configPdos="true">
<syncManager idx="0" dir="out"></syncManager>
<syncManager idx="1" dir="in"></syncManager>
<syncManager idx="2" dir="out">
<pdo idx="1600">
<pdoEntry idx="6040" subIdx="00" bitLen="16" halPin="drivecontrol" halType="bit"/>
<pdoEntry idx="6060" subIdx="00" bitLen="8" halPin="opmode" halType="u32"/>
<!--PARAMETRO POSCOMAND IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="607A" subIdx="00" bitLen="32" halPin="poscommand" halType="float" scale="838860.7"/>
<pdoEntry idx="6098" subIdx="00" bitLen="8" halPin="homemode" halType="u32"/>
<!--PARAMETRO HOMESPPED1 IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="6099" subIdx="01" bitLen="32" halPin="homespeed1" halType="float" scale="838860.7"/>
<!--PARAMETRO HOMESPPED2 IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="6099" subIdx="02" bitLen="32" halPin="homespeed2" halType="float" scale="838860.7"/>
<!--PARAMETRO HOMEACC IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="609A" subIdx="00" bitLen="32" halPin="homeacc" halType="float" scale="838860.7"/>
<!--PARAMETRO HOMEOFFSET IN SCALE SCRIVERE 8388607/X DOVE X SONO MM A GIRO MOTORE ESEMP: 8388607/10MM = 838860.7 -->
<pdoEntry idx="607C" subIdx="00" bitLen="32" halPin="homeoffset" halType="float" scale="838860.7"/>
</pdo>
</syncManager>
<syncManager idx="3" dir="in">
<pdo idx="1a00">
<pdoEntry idx="6041" subIdx="00" bitLen="16" halPin="drivestatus" halType="bit"/>
<pdoEntry idx="6063" subIdx="00" bitLen="32" halPin="enccounts" halType="s32"/>
<!--PARAMETRO POS IN SCALE SCRIVERE X/8388607 DOVE X SONO MM A GIRO MOTORE ESEMP: 10/8388607/= 0.0000011920930376 -->
<pdoEntry idx="6064" subIdx="00" bitLen="32" halPin="pos" halType="float" scale="0.0000011920930376"/>
<pdoEntry idx="6077" subIdx="00" bitLen="16" halPin="torque%" halType="float" scale="0.1"/>
<pdoEntry idx="606C" subIdx="00" bitLen="32" halPin="velmotore" halType="float" scale="0.00007"/>
<pdoEntry idx="603F" subIdx="00" bitLen="16" halPin="allarm" halType="u32"/>
</pdo>
</syncManager>
<dcConf assignActivate = "300" sync0Cycle = "*1" sync0Shift = "0" />
<watchdog divider="2498" intervals="1000"/>
</slave>
</master>
</masters>
I have hardware which runs at 250us and generic driver was not capable therefore I searched for other way of grinding avoiding with higher value of assign ... else with native chip driver is 0x0300 good enough
- lkt
- lkt
Yesterday 17:37
Replied by lkt on topic Post installation / problème pour ouvrir des images / Paramétrage de Python ?
Post installation / problème pour ouvrir des images / Paramétrage de Python ?
Category: Français
Hi,
funny thing, I had same problem, that's why I'm here.
See the output, especially last line:
AttributeError: Module 'numpy._core' has no attribute 'Inf'. Did you mean: 'inf'?
So, I edited line 34 in /usr/bin/image-to-gcode - changed .Inf --> .inf
It seems to be working
funny thing, I had same problem, that's why I'm here.
See the output, especially last line:
AttributeError: Module 'numpy._core' has no attribute 'Inf'. Did you mean: 'inf'?
So, I edited line 34 in /usr/bin/image-to-gcode - changed .Inf --> .inf
It seems to be working
- Hakan
- Hakan
Yesterday 17:17 - Yesterday 17:24
Replied by Hakan on topic Ethercat random jitter fix
Ethercat random jitter fix
Category: EtherCAT
You have actually switched off the pll, the synchronization code.
You can double-check that with the lcec.pll-err value.
If that one counts up/down it is on. If lcec.pll-err isn't moving it's off.
There is no difference in the code with "-" and syncToRefClock.
It is just two different ways to switch on the option. The actual code is the same.
The bug happens to to be when both options are used, it will be left off in that case
if I understand what I wrote by mistake once.
You can double-check that with the lcec.pll-err value.
If that one counts up/down it is on. If lcec.pll-err isn't moving it's off.
There is no difference in the code with "-" and syncToRefClock.
It is just two different ways to switch on the option. The actual code is the same.
The bug happens to to be when both options are used, it will be left off in that case
if I understand what I wrote by mistake once.
- bedouno
- bedouno
Yesterday 16:21
Replied by bedouno on topic HAL component for tangential knife
HAL component for tangential knife
Category: HAL
thanks for your great contribut and i will study it, i have searched for a while and i got this :' the trajectory planner process the G-code and pass the move sequence to a queue to be managed by the motion planner , so what if we can modify the sequence process the queue by our component our module to calculate the angle and specify the cretical angle points then inject this to the motion planner , we can use the lookahead trajectory planner strategy ' .
how you see that
how you see that
Time to create page: 0.196 seconds