Advanced Search

Update / Wednesday 5:52PM: 
finally found the root cause for this behavior.
Its line 25 in my pendant.hal

# --- ESTOP-EXT ---
net pendant-estop     <=  hm2_7i76e.0.7i76.0.0.input-29

when I comment it out, everything is fine. 

Now I just have to understand whats going on with this signal.

Regards
Sebastian

###############################

OK, I am one step closer.. I created a "virgin" configuration.. that worked fine and didnt show this error. Than I started copying my old config file by file into the new folder to narrow down when this error would be introduced.

And - believe it or not - it happens as soon as I include my pendant.hal file.

Here is a screencast. Its 100% reproducable.


As soon as "G54" is highlighted in the top left corner, everything is fine. When its "off", I always get this popup...

Does this make any sense to you?
this is my config.
github.com/SebastianMusser/LinuxCNC

so i dont understand how these correspond to physical pins on the remora board itself, do you still have to add those manualy in the code.
# estop and SPI comms enable and feedback

net user-enable-out <= iocontrol.0.user-enable-out => remora.enable
net user-request-enable <= iocontrol.0.user-request-enable => remora.reset
net remora-status <= remora.status => iocontrol.0.emc-enable-in


espacialy for the x-axis i dont see where the enable pin is or where the xp+, xp-, xd+,xd- are refferencd in the code here. i realy dot get it, the documentaion is not making sence.

# joint 0 setup (X axis)

setp remora.joint.0.scale [JOINT_0]SCALE
setp remora.joint.0.maxaccel [JOINT_0]STEPGEN_MAXACCEL

net j0pos-cmd joint.0.motor-pos-cmd => remora.joint.0.pos-cmd
net j0pos-fb remora.joint.0.pos-fb => joint.0.motor-pos-fb
net j0enable joint.0.amp-enable-out => remora.joint.0.enable

You are right  , i tried changing screen update and the vibration spikes up at the same rate.
My module is not real-time, it's a Python module and is built as an embedded tab of Lcnc. I dont think real-time is needed but i may need to find another way for it to not get affected by screen update.
 

I got it: the problem was that the [AXIS_X] section had the same settings as the [JOINT_0] section, basically setting the allowed range for the axis to the same range as the physical reachable positions. My corrected .ini values are now:

[AXIS_X]
MIN_LIMIT = 0
MAX_LIMIT = 455.0

[JOINT_0]
HOME = 0
MIN_LIMIT = -1
MAX_LIMIT = 455.3
HOME_OFFSET = -0.5

 

Hi all
I was looking for a way to control my vacuum table's vacuum pump from within axis. After reading the manual, searching linuxcnc's forums, I realised others were probably struggling with similar tasks (myst, dust extraction, ...), too. I could not find a proof cooked recipe. Below, you'll find what I am ready to go with. It is a proof of concept at the time. However, and since I use same/similar components the same/similar way in home automation, I am positive, it works in the real harsh world. Teaser wanted?
 
The KDialog message box is being called by M100, this reads the relays statii and displays as shown

So: let's go, just a remark: the editor seems to be disfunct, so I use my own marking:
Ingredients:
=====================================================
* github.com/ondrej1024/crelay
* a crelay compatible USB relay controller card, I used this one: 
* some time
Setting stuff up:
=====================================================
* follow the installation intructions of ondrej, should you fail (like me) at the first step (git clone git://github.com/signal11/hidapi.git), do this instead:
git clone github.com/signal11/hidapi.git
* If you'd like to have access to your relays over LAN. you can set it up as follows:cat /etc/crelay.conf  which crelay
 /usr/local/bin/crelay
sudo echo "user ALL=(ALL) NOPASSWD:/path/to/other/comands, /usr/local/bin/crelay" > user 
Replace "user" with the very username you run linuxcnc, check itcrelay 1
crelay 1 is on

That was a success, now get familiar with crelay:crelay -i

Detected relay cards:
                                        #
#1    Conrad USB 4-channel relay card (serial 00633CF4) 
crelay 1 on
crelay 1
crelay 1 is on

I guess there is no comment needed, ondrej's work is just perfect, isn't it?
So we can set relays from command line, as user "user" (cnc in my case) and read their status. Howto do it from within g-code?

M1xx comes handy:
=====================================================

Place a script similar to attached M100 into the directory specified in the .ini file's [DISPLAY] section under PROGRAM_PREFIX = /home/cnc/linuxcnc/configs/cnc0/macros

My path above needs to be changed to your definition.
Maybe, there is some rebooting and logging in/out/in required. I did not make notes on this.

Things to consider:
=====================================================
This approach is not for real time requiring tasks. However, I think, for these tasks:
* clamping stock via vacuum
* starting dust extraction
* and mybe even myst
real time is not required


Hope that helps someone else, too
greez
chris


 

I am just using fusion for this.

Great job! What CAD program do you use for drawing? It looks very real.

Is your module real time? I have seen similar issues with non-real time
functions being affected by LinuxCNC periodic screen update. 

Yup, it was U15. I put a new one in and it works just as before.
Thank you again for your awesome support!

/Peter

Hello Benny,
I'm not sure if I expressed myself correctly,the file spinport.comp causes the cylinder to retract when the y-axis reaches position 900 (while processing a program or jogging), allowing the axis to pass through the support.
When the y-axis reaches position 1600, the cylinder is extended again.

I haven't changed anything on the machine yet because I'm on vacation. But after my vacation, I want to install the new spindle support quickly. I tore down the support shortly before my vacation!
   

I tried to adjust gain of admittance module before but no luck.

I understand your point about increasing the update rate to reduce step magnitude while potentially increasing the number of steps.

However, if steps were the primary issue, I would expect the problem to be more pronounced at higher speeds, yet that doesn’t seem to be the case here. Additionally, I’ve noticed a sudden velocity drop that fails to meet the required speed, causing vibrations. This issue occurs simultaneously across all four motors and seems to happen approximately every 100ms. While it appears random, I haven’t yet identified the source of this cycle (admittance module is 10ms update rate), which makes it quite puzzling.

Thanks for the suggestion, but I have already installed a pressure monitor with an e-stop, which is set at 4.5 bar.
Unfortunately, this did not prevent the support from breaking off, for whatever reason, I don't know.
Therefore, I would like to install an additional safety device.

I ordered the first parts for the atc! The main pivoting hub, and some grippers. Basically the simplest and most complicated parts. I am using JLC to make the prototype so these will be my tests of the service to see what we get. Should be here end of next week. Exciting!

As I've refined this down it has basically become identical to the brother TC225 changer. It uses an identical BCD encoding system and 2 servos, one to pivot the magazine, and one to spin the platter geneva mechanism. I will have a custom pcb that has optical sensors and RC servo controller mcu that converts it all into 8x 24v IO (5 x bcd, and one fwd and reverse platter and one for the pivot). The linuxcnc side of things will reuse my brother tc225 osubs, with the addition of the pivot command. The pivoting will take 200ms, and the platter will take 400-500ms per station. So with clamping and z motion it should be about 1.5 seconds for the next tool, and 3.5 seconds for the farthest tool for a tool change. Plus 12 seconds on my spindle to start and stop form 40000rpm. I need to see if I can adjust that and use modbus to "know" when the spindle is stopped or at speed to adapt the dwell. Cause at lower speeds like 18k or 24k it should only take 2-3 seconds to start or stop.

I would think a faster update rate will decrease the steps.
You will get more steps but less in magnitude.
I guess you have some gain parameter between force and position.
Maybe try higher gain at low speeds? Since it seems to be a bit off, I mean.

Finally figured it out
I had to make true "is_opendrain" and "invert_output".

Alltogether:
setp [HMOT](CARD0).gpio.050.is_output true
setp [HMOT](CARD0).gpio.050.is_opendrain true
setp [HMOT](CARD0).gpio.050.invert_output true