Advanced Search

Look like more than just EMI causing lost Ethernet communications.

It actually it looks like the 7I97T card lost 5V power briefly,
since it does a full reset. I would check the 5V supply voltage,
current capability and connections.

In addition to tommylights suggestions, you might check that the contactor
contacts have arc suppressors, especially if they switch inductive loads.

Hi Guys,

I've re-controlled a Homag CNC router to use Linux CNC with MESA controls. It's was a complicated project, but for the last year it's been working well enough for me to be running commercial parts on it.

All of the motion hardware (mechanical / servos / drives) is what the Germans put in the machine 20 years ago. It uses Bosch ECODRIVE servo drives and has ball screws on x-axis and z-axis and a rack and pinion on y-axis.

The x-axis and z-axis work fine. The y-axis is "jumpy" when moving in the y+ direction. And smooth in the y- direction. I can clearly the position errors ramp up in halscope and then it appears to catch up and get back into position. With my hand on the gantry I can feel it jump / jump / jump going in the y+ and you can clearly see it in the tool marks. If I rapid at anywhere near full speed in y+ it will get wildly out of control and start slamming back and fourth and attempting to rip the whole 8,000 lb machine apart. But it rapids super smoothly in y-.

Mechanically the axis seems fine and there isn't anything like a dust collection hose that drags differently when going in a different direction. I've manually excessively lubricated the rack and pinion and it perhaps helps a little bit, but certainly doesn't solve the problem.

I recall probably spending about 10 hours attempting to tune the PID parameters and was never able to get it moving smoothly in y+. But I'm at the point now where I need to get it cutting smoother. So I am looking for any suggestions of things to try?

Thank you!

If I recall correctly I've PLL a fpga gpio at 50meg so to rid of that wizzy OSC extra part (im cheap, I know lol). If not 50M SPI then for sure it's full on 25Mhz and plenty capable kit. 

Doesn't matter, what's important to pay attention is something ain't right at 4Mhz, I suspect Lcnc won't be happy about that in fact. Perhaps the raspi is to be avoided if running on such a lazy tick?

I've added a few themes to Flex GUI. Notice the nice arrows on the spin boxes.

Blue Theme


Dark Theme


Blue Touch Screen Theme


Dark Touch Screen Theme


To add a theme you just add an ini entry.
gnipsel.com/linuxcnc/flexgui/ini.html#themes

JT

Aciera post=316563 userid=25994Maybe this documentation helps:
linuxcnc.org/docs/stable/html/user/user-...gramming-the-planner

From my experience the issue with the jerk is currently unresolvable, you can minimize it to some extent, but ultimately i have found no good solution to how the currently available linuxcnc trajectory planners handle modern code with short line segments and arcs and how the commanded velocity and acceleration settings work.  i think the only way to eliminate the jerk caused by high speed moves through short line segments and arc transitions where the motion velocity and acceleration rules come into play is to remove the realtime planner restrictions.  because the machine must be able to come to a complete stop by the end of the current or next move, it must change the machines motion to accommodate.  this means if the machine needs to be able to stop on a short line segment from a modern cam post output for adaptive clearing for example, and the commanded machine velocity is higher than it could stop when it gets to those short segments, the machine must decelerate to stay within the rule parameters. if the line segments are non uniform in length, the distance to stop requirement changes and the machine acceleration and deceleration is being changed very rapidly through each segment.  i find this is where i experience all of the violent jerky motion.  using G64 P and Q allows the motion path to make some of the smaller line segments into large line segments, but that just means there are fewer jerk points, not that the jerk is eliminated.  

I have pondered this and how it could be resolved, and I **think** it would require the rules be changed in the trajectory planner code.  I think a good compromise solution would be a calculation that uses look ahead and the machines acceleration settings and commanded velocity in conjunction with the planner calculating the path and setting the stop point to the next control point in the path that can be successfully stopped at under the currently commanded velocity and the deceleration configuration parameter setting.  if that means it requires 1 point or 1000 points to stop, it doesn't matter.

The example here being that to stop within the "1 point" would be where that point falls within the actual stopping distance for the machines parameters when the stop or feed hold command is issued, verse there being a series of very short line segments that may be only a few thousandths of an inch long), what would change with this method is the machine would maintain its commanded velocity through all of the path without having to slowdown for a "potential" call to stop.  this will give the machine the ability to move much faster and smoothly through the programmed path without the harsh acceleration and deceleration. 

In this regard the machine will always stop within the calculated distance of  (current velocity and deceleration rate + subsequent programmed point).  in this regard we are freeing up path velocity changes greatly which would result in much smoother motion.  the downside is the machine will stop a little slower in the event of a user call mid cycle.  

this would only change how quickly the machine stopped on those shorter moves.  because when the machine is moving at rapid or at higher feed velocities through longer segments or arcs, the stopping distance and time will always be the deceleration distance from the current velocity. 

just my thoughts, and i could be completely wrong, feel free to enlighten me if i am incorrect!  I will happily eat crow if it leads to a solution...lol

Chris 

Hi Guys,

i recently got one fanuc code and it has some Gcode for which I need help to find equivalent of these line in Fanuc for LinuxCNC. 
Please help me out with these codes:
1.  G5.1 Q1 R10
2.  G5.1 Q3 X0 Y0 Z0
3.  G5.1 Q0

Regards
Abhishek

i will check.
the mesa card should be wire with the ground ?

-no grounding
-bad/looped grounding
-bad/weak power supply
-error in wiring
-EMI/interference from drives/VFD
-PC with no ground connection
In that order, mostly.

I think I made all the modifications needed (and included my PIN_Slidersfx file in the TopEthernet16HostMot2_efx). 
When I now try to synthesize, I get the error "pin_slidersfxg_34 not compiled in library 'gui_analyze'. Should I call my file in another file too?

Thanks!
 

did you resolve? did you ever test the sim? and did you check the custom_config.yml settings by comparing to the latest sim version that gets copied over? those sometimes require updating as well if transitioning from older probe basic versions.

for my specific use case I think I would like to use the home switch to be able to home to the center of a pin that is inline with the pocket center (kind of like probing ridge center) and then use a preset amount of step counts per pocket based on the number of pockets in the carousel to divide it into that many moves for a full revolution of the platter. I am using a 2 pin geneva wheel so 1/2 rotation is one pocket. I would like to confine all of the hal into one file if possible to make implementation as easy as possible and have some options to be able to use the index method as well. kind of a one setup page allows all types and each type has a unique hal file that can be called from the ini. make it as modular and easy to use/setup as possible. ATC seems to be one of those things that scares most folks because of its complexity. I think having it made easier would be a good thing.

I think I know where the problem is.
for a start, i hadn't fitted a free-wheeling diode.
i've just put diodes on all my control contactors.



i've tried again and i have the impression that it's got worse because when i launch linuxcnc and deactivate the e-stop (F1), the message appears more regularly.

I try to control my chip conveyor, the message appears.
i try to drive my tailstock, the message doesn't appear ...

I realize that the commands that cause error messages are those driven by power contactors.

However, all my power contactors are controlled by command contactors.

sinking output:


drive with power contactor
e-stop / fwd turret / rev turret / convoyor fwd / convoyor rev

pilot with control contactor
tailstock output / tailstock input / enable drive / spindle fwd / spindle rev

I've never had a problem with controls driven by control contactors alone.

the video shows when i manually activate (with the control contactor) my turret. only the card is activated, the computer is not powered so linuxcnc doesn't work.
on the video i activate the contactor three times and 2/3 error and 1/3 no error



how can my power contactors disrupt the 7i97T card?

that is a linuxcnc error message being reported. that means your homing sequence may be incorrect or your homing method not correctly specified in the ini. see the docs of the home section for options. if the buttons are not synching up with the axis there is something missing. you will need to have a another look.

Hi,I’ve been working on my Bridgeport 412, and everything was going great until I discovered that the Fanuc control for the spindle motor is broken. Initially, I considered using the STMBL project with the Fanuc motor, but I’m running out of time, and the massive transformer required to run it is proving to be a nuisance.I’m now thinking about replacing the spindle motor and driver with a Chinese one. The replacement would have the same power (5.5 kW) but slightly more RPM (4000 instead of 6000). Since the machine could have been configured for higher RPM originally, I think this should be fine. The only adjustment I might need is to make a new pulley if the old one doesn’t fit.My machine primarily uses EtherCAT, but the Chinese servo I’m considering doesn’t support EtherCAT. It does, however, have CAN control, and I could also use its analog control interface if needed. The dimensions of the motor seem similar to my existing one, though I’ll need to double-check this weekend.I’ve gathered some information from the Alibaba seller. The entire kit (servo motor 5.5 kW 6000 RPM, servo driver, wiring, and resistor) costs $600 USD, excluding shipping. I estimate shipping will be an additional €200–300. I’ve never ordered through Alibaba before, so I’m curious about others’ experiences with the platform.Since I’ve never done this kind of replacement before, I’d really appreciate any tips or advice. Does this seem like a good choice, or are there other factors I should consider? Have you had any experience with replacing broken spindle motors or drivers? Does the price seem reasonable? I’ve assumed that items purchased on Alibaba are similar to those on AliExpress, and my experience with AliExpress has been that they deliver exactly what they promise.Looking forward to your insights!

Links(hope these will work for a while):
Motors Drivers


Best regards,
Andries

 


unfortunately it doesn't work with this file at the moment? 

  File "/usr/lib/python3/dist-packages/qtvcp/widgets/camview_widget.py", line 80, in __init__
    self.SUB = str.maketrans("0123456789", "₀₁₂₃₄₅₆₇₈₉")
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: the first two maketrans arguments must have equal length


both variants would be practical, but for me it would be even better to use the set rotation angles