Advanced Search

Hello, I wanted to add my configuration files to help some of you.  I know many of you have been like me scowering around for answers looking up every possible key word to get your system up and running.  Now I don't have a spindle hooked up yet this is just to get X Y Y2 Z up and running.  There was some configuration in the Leadshine Parameters as well that had to be made. 1 of those is Parameter 6092 (0x01) had to change to 10000, not sure why, but it just worked.  Also make sure all the slaves correspond as well with the PDO's. Just remember this is very basic in what I had to do to get the servos moving and running with one home/limit switch per AXIS.
 
 
 

 

The next time I see that error, I will try those things.

I am working on an Ursviken press brake retrofit to LinuxCNC and decided to document my progress, schematics, etc here, and probably ask questions along the way. If you have any hints or advice for me, feel free to say so.

This press brake came with a Compaq pc booting some form of MSDOS and a Mitsubishi FX-64M PLC. The machine had been forgotten in a warehouse for who knows how long until the current owner ended up buying it. After installation in the shop, upon first power-up, it complained of a depleted PLC battery. Sadly, the new battery didn't recover the lost memory. After multiple unsuccessful attempts to get Ursviken to get the thing working again, he showed me this project. I said I think I can make it run on LinuxCNC.

I pulled the PC and the PLC and installed a "Fanless industrial mini-pc" with 4 ethernet ports. For i/o I am using Mesa 7i80HDT + 7i36 + 7i54 and Beckhoff ethercat EL1409 16-inputs and EL2409 16-outputs.

Original 10 axis configuration was:
Y1 and Y2 = left and right ram (top die height)
X = backgage forward/backward motion
R = backgage up/down motion
Z1 and Z2 = independent left/right motion of the two backgage fingers.
Crowning: This feature currently has a mechanical malfunction so the customer asked me if I could leave crowning as an option for later if he decides he wants it. I said yes.
VDT = variable width bottom die, appears to have been present on the machine at some point but was apparently deleted.
PSB and PSA = automatic sheet lifter with a height axis and an angular axis. My customer requested to remove that because it will be in his way more than he uses it.

Target configuration:
Y1, Y2, X, R, Z1, Z2, and optional crowning. Y2 is slave of Y1. Z1 and Z2 are independent, except they run on the same rail and must not collide.

Y1 and Y2 speed and direction are powered by two servo valves, driving those with h-bridge outputs on the Mesa 7i54 card is working great. Plus, there are six 24VDC spool valve coils that need to be activated with relays in the correct combination for up, down, fast, slow, dwell, and decompression. Tonnage is set open loop via a proportional relief valve powered by an h-bridge output from the Mesa 7i54 card. 0% pwm = no pressure, 100% pwm = max pressure. The proportional solenoid coil had an RC snubber attached that interfered with the 7i54's current regulation, I removed that RC snubber, as the 7i54 neither needs nor likes it.

X and R axis each have a Baldor 90VDC servo with tachometer feedback to the Cybelec servo amps and encoder feedback to the PC controller. The Cybelecs' speed command is set with +/-10VDC from the 7i36 card.

Z1 and Z2 axis are DC worm drive motors powered by fwd/rev contactors and basic encoder feedback to the mesa card.

Crowning is a common AC 3 phase induction motor on a worm gear box driving an ACME lead screw protruding from the left side of the bottom bed. It is powered by a fwd/rev contactor.

I’m heavily dyslexic, so I write it myself but let ChatGPT make it readable, even though it changes the grammar more than I’d like — it’s still better.

Regarding the question of manual tool changes, what I mean is this:

Consider that you have a toolholder with two tools in tool-changer position 1. Because you’re making a very complicated part, you need more toolholders than you have positions in the changer. In this situation, you will eventually have to exchange the holders manually.

What I want is for the machine to ask me only when my input is actually needed. I’m not too concerned about a few unnecessary moves.

What I do want to minimise is the number of times I have to intervene, and the number of points where I can mess up. That’s why I want a single point of truth for the pocket number on a ganged toolholder.

Edit:
Examples of when it should not do a manual tool change:
Changing to a different pocket that already has the correct toolholder in it.
Changing to the same toolholder but to a different tool mounted on that holder.

And if it does need me to exchange a holder, it should have already rotated the turret so the pocket to be used is positioned in front

Dear all, I am new to Linuxcnc and trying to setup a bench test before connecting motors to my machine. I got Stepperonline A6 series 400W that allow analog control. I setup velocity mode on them and I setup a mesa 7i97T to control them with analog signal and get a feedback from the servo drive. I am sure I nailed all the wiring properly, but when I setup the MesaCT 2.1.8 to generate the configuration file I have doubts on what to put into the tool when it comes to selecting the axis Scale and then the encoder scale. My A6 drive have 17bit encoders that translate into 131072 pulse/rev. But I also see in the drive parameter that it is set by default 2500 lines ( that in quadrature should be 10000pulse/rev). my max velocity in the drive is set to 3000rpm.

My confusion is now to understand what parameters to input in the mesact config. for now I just want to test a motor (x axis) without any connection. Can someone expert chime in on the value to input in Max Velocity, Max acceleration, axis Scale, and encoder scale, to make this run and proceed to next step PID calibration? 
What I need is a clear explanation on what is SCALE vs Encoder Scale input field. I seem to be confused when I read the manual of the mesact. They seem to be the same thing. I understand that the scale should be calculated based on gear ration between encoder and motor etc etc. In my case the encoder is the motor encoder and the SCALE of the axis is for now not connected to anything. The plan is later to place this motor on a 1604 leadscrew (4 mm pitch).

Thanks in advance and apologies for this novice question, but could not find anywhere a clear explanation.

electric test

I think you may be misinterpreting how the invert parameter operates,
it does not change the state of the parport.0.pin-NN-out hal pin.
(It cannot as this hal pin would be driven by a hal signal)
but rather changes the physical output polarity. You cannot
detect this change in the parport.0.pin-NN-out hal pin but only by
measuring the actual parallel port hardware output pin.

I may be misunderstanding something, but I personally would not want to think about where I need to insert an M1 to manually change a holder. I want LinuxCNC to make that decision automatically based on the tool table.

That’s not actually the case in my system.
The diameter is only used on the “tool descriptor” entries, which represent toolholders, not real tools.
These descriptor tools never get used for cutting, so they never participate in G41/G42 or wear offsets.
But yes—this could just as well use the Pocket field. I didn’t think of that originally.
I will lrady make that change in the rest off this post.

Why I believe encoding the holder layout in the tool table is better

Here is a heavily simplified tool table to show the idea:
T5 P1 X0 Z0 D0 // holder #1 in turret pocket 1
T6 P— X100.34 Z-15 D10 // spot drill
T7 P— X120.876 Z-32.657 D10 // drill
T8 P— X140.298 Z-15 D10 // drill
T9 P— X160.3 Z-15 D10 // boring bar

T10 P5 X0 Z0 D0 // holder #2 in pocket 5 (5%5 = 0 → rear post)
T11 P— X100.23 Z23.456 D0 // parting blade

The descriptor (T5, T10, T15, …) stores the physical pocket number. so they are th single sorse of trus for this.

This means LinuxCNC can always determine:
Whether a manual holder change is needed
Whether the correct holder is already in place
Where the turret needs to rotate
Which tools belong to which holder
Whether a requested child tool even exists

If we don’t have this structure, I don’t see how LinuxCNC could determine where a tool belongs.
You’d have to manually encode the correct pocket into every single tool entry.
This leads to another issue.
Problem with the pocket-in-every-tool approach

Imagine two tools in CAM that both used to be in turret position 1.
But for a different job, you need to rearrange holders.

Then you must:
Change the pocket numbers in LinuxCNC for all affected tools
Update your CAM tool library to match
Remember to do this every time you rearrange holders
Add M1 manually at the right positions
Hope nothing gets out of sync between CAM and LinuxCNC
This is exactly the kind of workflow that causes human error.


Maybe I am overcomplicating things — but in my head this system makes sense.
It gives LinuxCNC the information it needs to make reliable decisions, without forcing the user to manually sync CAM, tool table, and machine setup every time a different combination of holders is used.

I'm a bit confused, if I want to start the system with an output at 1, do I apply setp... inverter true

This should show me the output activated, but I don't see it that way; I still see it turned off. I don't know if I'm misinterpreting it or if it's not working for me, which is why I left a video showing it.

At startup, the system,(for example the pin 1-out) does not change when an inverter is applied.
You can watch the video I uploaded in this thread to see what happens

Hi,
thanks a lot for the suggestions.

Just to clarify: I had already tried short Dupont wires and a short IDC ribbon, but without the “every second wire = GND” scheme. The cable was about 10 cm long and SPI still failed when the hot wire or motors were active.

Now I’m going to rebuild the SPI cable exactly as you described: ribbon cable with every second conductor GND, all GND wires tied together and connected to GND on both the RPi and the SKR. I will also add a separate, thicker GND wire between the boards and keep the SPI cable as short as possible.

One question: for the ribbon cable, should I place the signals like
GND – SCK – GND – MOSI – GND – MISO – GND – CS – GND – GND,
or do you recommend a different order?

I will report back with results after I rebuild the cable.

Sold.

Coordonnées polaires:
linuxcnc.org/docs/html/gcode/overview.ht...de:polar-coordinates

I suspect you dont need to do any of that. LinuxCNC tool tables aready define both tool number and pockets. Tool numbers are unique, but pockets dont have to be. 

There is a carousel tool changer comp which supposedly already works with the Schaublin tool changer.
www.forum.linuxcnc.org/10-advanced-confi...carousel-toolchanger

So lets consider your example.
For a job we mount all of these tools. The first three go on the three postion gang tooling holder you have. We mount that in turret position 1 which in the tool table is pocket 1.
T1- Spot drill - Pocket 1
T2- Drill - Pocket 1
T3- boring bar - Pocket 1

T4 - RH VCMT turning tool in pocket 2
T5 - Kurling tool in pocket 3
T6 - LH VCMT turning tool in pocket 4
T7 - but we also need a threading tool, so that is on another tool holder, and will be manually changed into pocket 1.

T8 - Parting tool on the rear tool post, which we will call Pocket 5.

I have not looked at the code of that carousel.comp, but suspect it only trigers activity of the tool holder when a pocket in it's assigned range is called.  So if pockets 1-4 are assigned in the comp to the carousel, then the behaviour would be:

At the start of the program, I would add an M1 and a pop up message to remind that the gang tool has to be in pocket 1.
The M6T1G43, the carousel indexes back to pocket 1, if not already there.
First three M6TxG43, the carousel is not called, LinuxCNC just assigns the correct called tool, offset, orientation and nose radius, and continues.
M6T4 G43 - Turrent indexes once, then LCNC assigns the correct called tool, offset, orientation and nose radius, and continues.
It would be at this point that I would have programmed in the M1 stop, to manually remove the gang tool holder with it's T1-3, and load T7.
M6T5 ( and T6) Indexes around one.
Calling M6T7G43 would rotate the turret back to pocket 1, with its changed tool.
M6T8G43 I would expect to again do nothing with the turret and just load the offsets for the parting tool.

It would probably be a good idea to add another M1 and text pop up at the end of the program to remind to reinstall the gang tool in pocket one, so the program is ready to go on a restart.

Of course I could be wrong about that carousel.comp not moving the turret on a tool change which calls a pocket outside it's range (or no pocket). But if that is the case, it would be best to modify the comp. Misusing the tool diameter for this would lose the ablity to do tool radius compensation, which is important on a lathe.

CAM software doesn't care where the tools come from. It just assumes the appear with the correct offsets, orientation and radius.

For tool table hygiene, it might be good to standardise like anything in pocket 1 is called T1xx, in pocket 5 -->T5xx etc.
Cheers,
Mark

 

There might be something in the cia402pv code.
The original cia402 component didn't allow mode switching, it took the first csp_mode value at startup.
I need to at least go over that part to make sure mode switching works.
But I doubt that's the reason.

Start using the debugging tools. Halshow and maybe halscope to follow the values over time
to find out the reason for the following error.