Advanced Search

Ul wrote:

Ist ein Oszilloskop vorhanden? Falls ja, einfach ans Glasmaßstab anschließen, auf single shot stellen, Triggerspannung einstellen und die Achse joggen.
Ansonsten kannst du probieren mit dem Signal einen MOSFET und damit eine LED zu schalten (mit Diode in Serie am Gate, damit er auch geschaltet bleibt). Wenn bekannt ist, wo das Signal ist, kann man die Stelle anfahren und die genaue Spannung mit dem Multimeter messen. 


 

Nein, ich habe leider kein Oszilloskop und selbst wenn, es würde ja nichts ändern, wenn das Oszi ein schwaches Signal erkennt, aber LinuxCNC nichts damit anfangen kann weil es einfach zu schwach ist.
Ich habe mir einfach die falschen GMS ausgesucht, hätte ich da vorher danach recherchiert, dann hätte ich wohl andere genommen.

Es ist wie es ist und es bleibt auch so

Danke für den Tipp

Gruß
Olli

I just found out that I am subscribed to your youtube channel since over 4 years ago. Very interesting videos about your mill and linuxcnc. Thanks a lot.

Hi, JT! 
thanks a lot. 
Its works fine.
Also im used parent.slider1.setSliderPosition(int) for setting needed value with 'if' to controlling the range without changing min/max.

Best regards
 

I guess one way would be to loop back the commanded position to the feedback position
when homing, by using the mux2 component.

Sorry, put reply in wrong thread...

Hello friends,

I want to make LCNC "Unhome" when power-off (servo-off).

I'm using AXIS. 

How do I do that ?

 

andypugh wrote:

This isn't an answer to your question, but have you tried hal_gpio on the Odroid?

 

Actually no, I knew of the component but I don't think it dawned on me that it used gpiod. In that case it would certainly work for something like an MCP23017 or a different I2C IO expander. The catch there is I don't know if it would technically be "realtime" unless an IRQ was attached via interrupt GPIO. I believe that specific driver will run in polling mode if an IRQ isn't attached. I could be wrong about that. This would be limited to GPIO as they have to register as gpiochips. In my head I was thinking of a component that would pretty much do exactly this but be expanded out to use other types of chips like clockgens and ADCs. Some clockgens have good command control so they could be used like a Mesa stepgen with a GPIO pin for direction. Maybe it's better just to split up the components but then it's the whole segmentation thing, I've been messing with LinuxCNC for about a decade and it didn't even dawn on me that hal_gpio used gpiod. So it'd be great to do an all-in-one component but that might get very messy making sure all the drivers are loaded etc.

andypugh post=335457 userid=723I was actually wondering the same thing about the serial port las month:

sourceforge.net/p/emc/mailman/emc-develo...arg.org/#msg59226340

Maybe a realtime modbus driver through the onboard serial port could work, for example.

If you can drive the serial port by sending bytes with outb() / inb() it might work, though you would end up having to re-invent the drivers as non-blocking code.

I've been asking about RT serial around here for over a year now, you're popped in on one or 2 of the threads. I definately would not use modbus. RS485 is (generally) half duplex and requires flow control, it's multi-drop, etc. I don't think Modbus can ever be any more realtime than USB but I could be wrong. My Idea for using UART is single host interface just like Mesa SmartSerial and just sticking to simple full duplex just as Smart Serial does.

I've been banging chatgpt from every direction on the UART thing and the result is the Intel 8250 driver is pretty much perfect as is for real time with a custom protocol. Might sound like blasphemy to someone like you who know what they're doing but I've found that if you hit the bot with enough contention you can come up with fairly solid answers in the end. Seems just plain UART with the FIFO interrupts is just fine, no hardware flow control or anything else required.

Another somewhat sticky point that I didn't bother mentioning above is because there is no real GPIO on the H-series boards I need to get creative for a hardware interrupt for the I2C chips. These don't have a GPIO controller like some other boards do. It seems the CTS (and RTS) pins can be stolen from the UART and repurposed and likely still have a usable UART just without flow control. So I actually need a kernel module to set that up. That's what actually got me back on this kick, I was messing with an vendor I2C touchscreen kernel driver. That requires the I2C bus with an INT (IRQ input) and RES (output) GPIO pins. I was able to get about halfway there hanging the IO expander off the I2C bus and binding the MCP pins as the IO it almost worked, problem was I couldn't generate a real interrupt without an single IRQ capable input pin so I gave up at the time. Once I realized I might be able to steal the CTS pin for the I2C interrupt it snowballed back into me thinking "can I get this stuff working in LinuxCNC?"

So at the moment I'm just trying to get the CTS interrupt working with the MCP23017. If that works I might just try it out with the hal_gpio component. At some point I'll see if I can get a basic RT UART comp going. Once I know it all will probably work I'll try making it useful.

How to disable following error while homing ?

Background:
When we use "internal homing function" with EtherCAT servo driver, 
command position from LCNC and feedback position difference become large.
We can avoid this by setting f_error with large number, but I don't think it is good idea.

Are there any settings or something to do this ?
 

Hi Cmorley

I made some adjustments to the brushed_metal_color file. Mainly to improve gcode readability (the white font was difficult to see).

If there's a space between the axis letter and the value in the gcode, the letter and value colors aren't applied. Is it possible to fix this?

Another idea and suggestion. I'd like the macro button (the last, first, or maybe all buttons) to have a drop-down menu so I can easily add more macros within easy reach. Something similar to the screenshot.

Hi Endian, I don't have anything for LCNC but I think I have some probing routines in a TwinCAT project and I can see if there is anything helpful in there.

I also posted an issue to your codeberg page for your converter for the EL3074.

I went back and carefully made the mods again, in case I missed something, but it still reports errors. Through a great deal of trial and error, I found that some of the configurations marked for removal must remain in the XML file for the program to run without error. Deleting any of the 0x60xx vars below cause many errors. Regardless, even with all the other mods in place, it's still stuck at "PrOp."

      <slave idx="0" type="generic" vid="00000a88" pid="0A880002" configPdos="true">
         <dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="0" />
         <sdoConfig idx="60FE" subIdx="2"> <!-- -->
            <sdoDataRaw data="00 00 03 00" /> <!-- set the bit mask for out1 and out2 (bit 16 and 17 should be 1) -->
         </sdoConfig>
         <!-- Note: 0x2007 address default value is 0x00000006, not what the manual claims -->     
         <syncManager idx="2" dir="out">
            <pdo idx="1600">
               <pdoEntry idx="60FE" subIdx="1" bitLen="32" halPin="set60FE-1" halType="u32" />
               <pdoEntry idx="6040" subIdx="00" bitLen="16" halPin="cia-controlword" halType="u32" />
               <pdoEntry idx="6060" subIdx="00" bitLen="8" halPin="opmode" halType="s32" />
               <pdoEntry idx="607A" subIdx="00" bitLen="32" halPin="target-position" halType="s32" />
           </pdo>
         </syncManager>
         <syncManager idx="3" dir="in">
            <pdo idx="1a00">
               <pdoEntry idx="6041" subIdx="00" bitLen="16" halPin="cia-statusword" halType="u32" />
               <pdoEntry idx="6061" subIdx="00" bitLen="8" halPin="opmode-display" halType="s32" />
               <pdoEntry idx="6064" subIdx="00" bitLen="32" halPin="actual-position" halType="s32" />
               <pdoEntry idx="60FD" subIdx="00" bitLen="32" halPin="digital-inputs" halType="u32" />
            </pdo>
         </syncManager>
      </slave>
 

Hi everyone,
I’m working on a Yaskawa CACR-SR (BE1 series) servo drive. In general it works, but from time to time I randomly get A20 or A60 errors.

I have two identical drives, and I’ve already narrowed the issue down to the specific board shown in the photo. I was planning to replace all the electrolytic capacitors and also the film ones (I’ll probably do that anyway, given their age), but I also noticed component D20, which looks burned/blackened and has no readable marking.

I’m not an electronics engineer, but I’m quite good at soldering and I have a multimeter, so I can take measurements if needed. I’d really like to repair this drive because I have a milling machine that I only use as a hobby, and I simply can’t afford a new servo drive since I’m still young.

Could someone please help me identify exactly what D20 is (diode type and value), or point me to other likely components that could be causing these errors?

I wrote on this forum because I saw that in another topic an engineer had the same problem as me, but since it is an old topic I thought it was better to open a new one

Thanks a lot in advance for any help!
       

I am having trouble interpreting this thread, but it seems to have similar debug info to my problem:
forum.linuxcnc.org/ethercat/51505-new-hardware-trouble?start=0
Could my problem be EoE related?

I followed your suggestions and am running into the following errors:

Machine configuration directory is '/home/kurt/linuxcnc/configs/BaxEDM-2axis-WireEDM'
Machine configuration file is '2axis-WireEDM.ini'
INIFILE=/home/kurt/linuxcnc/configs/BaxEDM-2axis-WireEDM/2axis-WireEDM.ini
VERSION=1.1
check_config: Unchecked: [KINS]KINEMATICS=baxkins
PARAMETER_FILE=baxedm_mm.var
TPMOD=
HOMEMOD=
TASK=milltask
HALUI=halui
DISPLAY=axis
COORDINATES=XYZ
KINEMATICS=baxkins
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
libnml/buffer/shmem.cc 320: Shared memory buffers toolCmd and toolCmd may conflict. (key=1004(0x3EC))
libnml/buffer/shmem.cc 320: Shared memory buffers toolSts and toolSts may conflict. (key=1005(0x3ED))
libnml/buffer/shmem.cc 320: Shared memory buffers emcError and emcError may conflict. (key=1003(0x3EB))
emc/iotask/ioControl.cc 786: can't load tool table.
Starting HAL User Interface program: halui
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Found file(REL): ./2axis-WireEDM.hal
Shutting down and cleaning up LinuxCNC...
*** baxkins.comp setup ok
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments

Debug file information:
Note: Using POSIX realtime
./2axis-WireEDM.hal:51: Pin 'lcec.0.0.actual-velocity' does not exist
5318
Stopping realtime threads
Unloading hal components
Traceback (most recent call last):
  File "/home/kurt/linuxcnc/configs/BaxEDM-2axis-WireEDM/baxuipushbuttons.py", line 168, in <module>
Traceback (most recent call last):
  File "/home/kurt/linuxcnc/configs/BaxEDM-2axis-WireEDM/baxmisc.py", line 462, in <module>
    while True:
KeyboardInterrupt
    time.sleep(0.01)
KeyboardInterrupt
baxkinsdata: not loaded
<commandline>:0: exit value: 255
<commandline>:0: rmmod failed, returned -1
<commandline>:0: unloadrt failed
Note: Using POSIX realtime

This is the entirety of the linuxcnc command info
When I type "lcec_config" into the command line I get command not found.

Changing dcConf didn't seem to change anything...

Is there a guide on the linuxcnc forums to setting up Twincat with LinuxCNC? I can't find out, but I could try to figure it out without one.