Advanced Search

First get familiar with the estop-latch component. Chain 2 together. One for the estop button and another for this component.
Then you could try a time delay component.

I that does not work out, write your own component that monitors the fault pin. When it changes state, set a flag (maybe call it error_set) then in another variable (error_time) accumulate the time its on for
if (error_set){
  error_time += fperiod;
  if (error_time > error_delay) 
    do something
  }
}

Hey,elovalvo,I've installed your image in my rasppi5 machine,but met a problem while I installed the linuxcnc-ethercat ,I cant run "sudo apt install -y linux-headers-$(uname -r) ethercat-master linuxcnc-ethercat",because I cant find the right kernel version of header,could you offered that ? Thank you

Hello folks. I have a pin in a hal component. This pin becomes True when a fault detected. I wanna make e-stop if this pin remains True for a period of time. The key thing is time here. Because when machine goes e-stop off state after estop-on state, the pin remains True for a while, but it is not a fault signal. It is only reset state of the device. After some time, it goes to False and starts to operation. If i evaulate this pin without any operation, i am not being able to make estop-off, because the signal is being True at that time, and machine is doing estop again.

According to this scenario, i need a hal component which gives True output if the input pin remains True for a period of time. I've used oneshot-edge components but they don't meet my demands. They act like when input pin gives the expected edge, they give output regardless of time of input pin. If there is no appropriate component in LinuxCNC, i am gonna develop intermediate hal component to do it. If you have a solution, plase share it with me. Thanks.

Berkay

if the joints were cables wrapped around a drum, would it still be appropriate to transform cable length the cartesian coordinates

Yes, as long as the cable gets wound up uniformly (ie the coil does not change diameter due to stacking of the cable on the drum).

or would you actually resolve that back to stepper motor steps in order to define a cable length?

This is done in the [JOINT_n] section of the ini file. The 'STEP_SCALE' value defines how many steps the motor needs to rotate to move the joint one machine unit (inch/mm).

grblhal is a good model for how remora is now, across multi framework.
Im mainly trying to do the mbed ce because it has better G0/H7 support (nobody making F4 boards) , but it supports everything that has remora firmware. its not as easy to setup as mbed was, but its easier than cubeide. Eithwer way, I can figure out this DMAMUX on the new stm chips, and mbed ce has an SPI DMA api, so I thought I would give it a try

But its not as if Mbed is dead, just Arms support/development of mbed. the CMSIS RTOS is still there, as well as the new community fork. the part that is gone is the tidy easy to use prepackaged mbed.

The error occurs after a tool change.

**************************
Cycle Start
↓
Move to [Tool_change_position]
↓
Replacement instructions
↓
Go to [VERSA_TOOLSETTER] and measure the tool
↓
Go to WORK
↓
Z limit error

Linear move on line 17 would exceed Z's negative limit
Linear move on line 17 would exceed joint 2's negative limit
invalid params in linear command
error parameter is [3.000000]
Cannot switch pages while in AUTO mode

****************************

It looks like the z-axis is now jumping out of the machine area.

Yes, I need to look into this some more. I'm not sure where / how things got broken as we've confirmed that the NVMPG firmware has not changed in recent shipments.

This topic came up nearly 2 years ago when I started to look at the STM32H7.

forum.linuxcnc.org/18-computer/42276-rem...spi?start=590#252207

Something that we'll need address at some point and some learning curve as Mbed does make things simple to have a code base for multiple targets. The use of submodules was suggested but I never really got deep into understanding how we could re-structure things. 

Thanks! that has fixed it

slowpoke wrote:

Well thanks to spumco for providing this link...
spumco post=294853 userid=28776

github.com/AlexmagToast/LinuxCNC_ArduinoConnector

I now have a little nano board communicating with HAL both inputs and outputs. So I just need to port the communication code from the nano test board into my ARM project and rejig the messages a bit and with a touch of luck I should have bidirectional data flow from HAL to my board. Hopefully the .py script is easy on the Linux overhead.
 

ArduinoConnector has major issues that the author does not seem to want to fix as they've been working on a V2 branch. The last commit was my friend fixing a bug I found before I dropped it. I wasted alot of time with ArduinoConnector, I made 2 custom PCBs around it just to realize it had so much lag it was unuseable (see my git issue).

Maybe version 2 will be better, but the main branch can't handle an MPG. You will wait literally 10 seconds for it to count the pulses and relay them back to LinuxCNC. All the lag comes from the Python side, the MCU side is fine. It's a great idea, with some great features. Unfortunately it's currently unusable unless you just want to push a couple of buttons.

Thank you ,I've read the doc of screen_options in qtvcp widgets.I think it may be exactly what I want ,but the doc is lack of more sample code of usage ,so it's not very easy for me to use it .Not like the other qtvcp widget such as ActionButton,very easily to use.the screen_options seems to require more background knowlege ,would you show some sample use of this widget ? I'll be very appreciateful of that .

If they are anything like the ones i had, and they sure do look and sound so, they have ABC not ABZ signals, all are incremental outputs, but not linear at all, the rate changes depending on motor angle.
Open hal scope and monitor all 3 pairs, use something to consistently turn the motor, slowly, see the width of each line change at a certain point.
I really hope they are not the same, as those are useless for anything except Yaskawa drives.

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!

    I recently had a terrible time trying to implement an older (90's) Yaskawa servo motor with "incremental" encoder UTOP1. It would run rough in one direction and smooth in the other with an AMC brushless drive and 7i77. I opened the encoder cover and found odd looking tracks (see 1st and 3rd encoder band on picture). I'm curious on the purpose of it? It's clearly not a standard incremental evenly spaced grating. The additional 3 sections that repeat 4x I assume are the commutation hall signals and the inner 2 are the index. Maybe open yours and see if the tracks are odd looking?  

i left this machine sit here for a few hours turned on and now this is my output of ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: wlp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 66:98:11:36:d9:48 brd ff:ff:ff:ff:ff:ff permaddr 9c:2a:70:32:72:49

where did my wired networks go?