Advanced Search

@grandixximo
According to my understanding, the P-tolerance is intended to prevent the need to slow down to speed 0 in a corner and to reduce the speed before the corner to such an extent that the 'corner' can be driven through without exceeding the jerk and acceleration.

RotarySMP wrote:

I just realised that the main Gmoccapy screen now behaves nicely. However, now I no longer have the tab for Andy's lathe macros.

You still have it - it just moved to the user tab section.

Damn,
I am sick of this device!
Had it working with one register, redid it all properly, wrote a script to set them all and now none of the vfd registers are showing. I'll check dmesg again later....

I'll look at your tip... 

10K wrote:

Problem came back! Something updated, possibly Debian, and now my screen is too wide again. See attached photo. What's different is that I can't set it to Start as Windowed and then back to Start as Fullscreen to fix the problem. Also, the modification to Gmoccapy by alex_sar earlier in this thread does not work anymore, although it did for 6+ months.

My touchscreen monitor is set for native resolution, 1024 x 768

I have the latest version of Debian Bookworm.

I thought that updating everything might help, so I updated LinuxCNC from 2.92 to 2.93 and Gmoccapy from 3.4.6 to 3.4.8. No joy.

Help me newbynobi, you're my only hope!

Can you post your configuration? Its this still an issue with LinuxCNC 2.9.8 ?

I just realised that the main Gmoccapy screen now behaves nicely. However, now I no longer have the tab for Andy's lathe macros.

It's not really an error in your INI file. The lathemacro just needs too much space for some reason and in ntb_user_tabs is just more space available

Hans got me sorted out. I had an error in my INI.
He had me replace:
EMBED_TAB_LOCATION = ntb_preview
with
EMBED_TAB_LOCATION = ntb_user_tabs
Now it has stopped scaling.
Big thanks to Hans for getting that straight.
Cheers,
Happy Mark

from your latest output, both PDO entries are clearly 16-bit and your XML uses bitLen="16", so that part looks correct.

also, halType="u32" does not mean the PDO is 32-bit. It only affects how the value is exposed in HAL.

it doesn't look like a bit length issue anymore.

given that, I would focus on:

- XML syntax issues (even a small typo can break it, and LinuxCNC may stay silent — checking dmesg helps here)
- verifying that the PDO/SM structure matches exactly what `ethercat pdos` reports
- keeping the mapping minimal until it reaches OP

once it reaches OP, then refine the mapping.

I struggled a lot because it was a topic I didn't understand at all. I added the pdos and the lcec_configgen result, but I didn't understand what kind of structure I was supposed to create.
When 32 bit = 16 bit
ceka@debian:~$ ethercat slave
0 0:0 OP + XINJE-DS5C1 EtherCAT(CoE) Drive Rev4.0 v3.7.70
1 0:1 OP + XINJE-DS5C1 EtherCAT(CoE) Drive Rev4.0 v3.7.70
2 0:2 OP + XINJE-DS5C1 EtherCAT(CoE) Drive Rev4.0 v3.7.70
3 0:3 SAFEOP+ERROR E EM32DX-E4   ????????????????????????????????????????????
ceka@debian:~$

SAFEOP+ERROR E EM32DX-E4

old now

ceka@debian:~$ ethercat pdos
=== Master 0, Slave 3 ===
SM0: PhysAddr 0x1000, DefaultSize  128, ControlRegister 0x26, Enable 1
SM1: PhysAddr 0x1400, DefaultSize  128, ControlRegister 0x22, Enable 1
SM2: PhysAddr 0x1800, DefaultSize    5, ControlRegister 0x64, Enable 1
  RxPDO 0x1600 "RxPDO0-Map"
    PDO entry 0x7000:01, 16 bit, "OUT"
SM3: PhysAddr 0x1c00, DefaultSize    7, ControlRegister 0x20, Enable 1
  TxPDO 0x1a00 "TxPDO1-Map"
    PDO entry 0x6000:01, 16 bit, "IN"
ceka@debian:~$

lcec_configgen
<slave idx="3" type="generic" vid="0x00004321" pid="0x01100073" name="D4">
      <!--EM32DX-E4-->
      <syncManager idx="0" dir="in"/>
      <syncManager idx="1" dir="out"/>
      <syncManager idx="2" dir="out">
        <pdo idx="1600">
          <!--RxPDO0-Map-->
          <pdoEntry idx="7000" subIdx="01" bitLen="16" halPin="out" halType="u32"/>
        </pdo>
      </syncManager>
      <syncManager idx="3" dir="in">
        <pdo idx="1a00">
          <!--TxPDO1-Map-->
          <pdoEntry idx="6000" subIdx="01" bitLen="16" halPin="in" halType="u32"/>
        </pdo>
      </syncManager>
    </slave>
  </master>
</masters>
ceka@debian:~$


Would the `lcec_configgen` command help? Could someone write the correct configuration for me?


 

Always something new to learn. Write-once sdos, ok.
If you aren't too bored of the device you might try with initCmds
if you understand the format of the input file. I struggle there but
there are examples I guess.

I always wonder how to program those things.
Programming I see as the big bottle neck for 5-axis.
The type of machine seems to be of very limited practical use . 


 

Same here. with dual boot things get complicated when I want to replace one OS and keep the other. My fix has been: one hdd = one os.

Just to be safe, I pull all bootable drives and leave only the one connected, to which I'm installing the OS. This greatly reduces my chance of making mistakes when selecting what installs where. My dual boot mini-pc contains two SSD's.

That said, I can see the case for dual booting on one drive, especially if the machine only has one drive slot. Did you see  wiki.debian.org/DualBoot/Windows  ?

Wow!
Two things I see especially:
1. Wireless probe, probably bluetooth.
2. Run the program, providing feedrate override by spinning the jog wheel. Then switch over to programmed feedrate.

Success! I used Ethercat download to set the parameters for one VFD register to measure the bus voltage instead of the ethercat-conf.xml file and I got a reading that changed from time to time. At one stage it was at 321.0 which also showed up on the vfd console. This is meant to be intermediate DC power which should be  1.414 x mains power input. Working backwards, that was 227 volts (should   be 240 volts). So learnings are:
1. Once a SDO is set, it can't be changed
2. You need to set the SDO's via Ethercat download, not via XML
3. SDO's are cleared when the slave is powered off. 

Out of time now but It looks like I'll be able to get this going now. It was frustrating not being able to see anything at all.

Thanks for the help....
 

Yes, it certainly pays to get a quote from Beckhoff first. Some of their modules are really cheap and others like encoders 5151 etc al are expensive here in Australia.