Advanced Search

Yes.
Yes.
Yes.
...
But first you have to stop thinking DMG or Dosan have good controllers, most industrial controllers suck badly for some work while being very good for some other work.
Point being, C1, C2, C3 are very wrong names for rotary joints/axis, LinuxCNC use A, B, C and they are tied physically to X, Y, Z, in that order so very easy to remember and use.
As for the rest, the above Yes's are for everything else you asked, LinuxCNC can do 5 Axis (can do 9 axis XYZABCUVW and each of those can have more than one joint/motor/drive controlled separately), yes you can use a parallel port or two or three if you need more inputs/outputs, parallel ports can be set to IN/OUT/X mode, etc etc etc .... the list is very, very long.
And most importantly, YES, start building the machine, no matter what i or others say, just build it!

Edit:
Just read it again, C are spindles in axis mode so forget the part of me complaining about it.

No, homing to index is common and fully supported.

I'm just saying that the actual index hal pin is not useful
for homing. The index-enable pin is what's used to communicate
index information from the hardware/driver to LinuxCNC

That is, this hal statement:

net phaseZ [HMOT](CARD0).encoder.00.input-index

Doesn't do anything useful.

But this hal statement:

net b-index-enable joint.3.index-enable <=> [HMOT](CARD0).encoder.00.index-enable

Allows LinuxCNC to enable index detection AND allows the driver to inform LinuxCNC
when the index has been detected.

To test whether the index hardware is working (assuming you can move the axis past
an index mark), you would:

With LinuxCNC running,  use halshow to watch the signal b-index-enable
and then with either halshow or halcmd, set b-index-enable true"

halcmd sets b-index-enable true

halshow should now show b-index-enable true

now, if you move the axis past an index mark, b-index-enable should go false.

This is how you test for correct index operation.

Hi everybody.
I would like to build a CNC machine with 5 axis MillTurning.
Its basically like the DMG Mori CTX BETA 800 TC.
I work everyday as a cnc programmer with DMG(Siemens/Celo) and Doosan(Fanuc).
It would be a small form factor and only for light materials, like aluminiu or brass.
My ideea is :
X, Y, Z as linear axis.
C1, C2, C3 as rotary axis.
C1 is the rotary axis of the spindle head
C2 is rotary axis of main spindle (G54)
C3 is the subspindle (G55 for ex.)
BTW i know that in DMG the C1, C2, C3 are in angular mode, in turn mode is S1, S2, S3.
The Spindle head will be with a BT30. (i will machine all turn base tool holders for BT30)
The driver part i would like to use 400W to 750 W servomotors.
I would like to use Parallel port for this setup but i get the feeling i'm limiting the performance of the build.
For the moment i have some stepper motors (JSS57P2N) would like to experiment.
The build size will be maximum of 500mm between arbors (S2, S3), the Y axis max 150 mm travel, X axis 200 mm travel.
The problem i face right now is it posibil to make this cnc with linxcnc or i have to buy a different controller and software?
For now i have DELL Optiplex 745 with Intel Core2Duo CPU and 4GB Ram, AMD video card and i get about 12000ns
 latency test.
I'm trying different configurations but do not see something compatible for my purpose.
If someone build something similar from DMG style could you guide me.
Thanks
 

What value do you have for P in the ini file, if any?
And what value does the servo period have?
Or is this a parallel port setup?

I don't quite understand, but that means I could never use it as a homing device? my encoders are 2500 pulses/ 10000 pulses quadrature hole.

I have been trying to run a fairly simple profile on my lathe- a radius and then a straight z axis move. during the the final g71 pass and also the g70 pass, the x axis twitches after going some distance, gouging a bit into the profile, around 0.3 mm into it whereas it should go straight without the x axis moving. I am unable to troubleshoot this problem at all. 

i am posting a link to the video of the problem I am facing, you will be able to see the x axis unwantedly twitch a bit in the last 3-4 seconds if you look closely. any help is much appreciated.

youtube.com/shorts/7KZHbUTbIng

Very odd, the only thing I can think of is that
there's something wrong with the supplied
field voltage (not filtered?) or the field voltage
sensing on the card is faulty.

What is your field voltage and what does
the 7I76 field voltage hal pin read?

You would need to have the sserial mode set to 2 to
be able to read the field voltage hal pin, so in the
hal file, change:

sserial_port_0=00xxxxxx

to:

sserial_port_0=20xxxxxx
 

are you on the soft limit or the hard limit? if the hard limit, then set a home offset so you have a bit of cushion for drift on power cycling. if its a hard limit switch, in probe basic in the side bar tab for "WCS" there is a button for LIIMITS OVERRIDE. this should ignore the limit switch and allow you to jog away. but this isn't really going to fix the issue over all. you should set the home offset with enough distance away from the limit towards the useable axis travel side so it doesn't ever encounter this situation.

hello,

I see the TC3 on your screen .. I did TC3 master to lcnc master configurator but it is not tested with the SoE drives ... maybe it will help you

let me know if it helped

regards
 

kubes wrote:

Additionally, I have found incorrect and inaccurate details regarding the setup of absolute encoders and how LCNC handles them in both document and forum searches.

Yeah search is fuzzy on the forum and utterly useless on google lately.
And this is a rare topic, so not much to go on, but more and more users have similar setups with absolute encoders and homing to index and EtherCAT, mainly due to inrush of cheap china drives with haphazard user manuals leaving users to pretty much figure stuff by trial and error.
-
I did a retrofit with absolute encoders, used the "immediate homing" feature in LinuxCNC as it was simpler for them and more in line with their type of "one off" work.
-
Did you test adding a bit of HOME_OFFSET? Usually negative values, not always.

hello,

Some time ago, Sebastian did the config ..

regards
 

Now that you confirm this feature is supported and should work. Which would have been good to know in the first response. I can dig deeper, I assume this is exposed in the hal, correct? Is there a special condition or hal pin for jog while within soft limits? While, there is tons of ductiontation, it is hard to find it when you don't know what you are looking for. If I had to guess, the issue is that it's not a direct EtherCAT issue (has it just a HAL component), but rather a dependency on the configuration from a configuration wizard.

I do agree a machine should never be beyond the limits, but if the logic is just a straight greater than or less than than I think there could be an edge case that needs better logic. Maybe this has already been addressed. I have 23-bit encoders, so that is > 8.3 million per rev. So even with the translation to machine units there is a very very small "error" factor. Meaning the "actual" location will fluctuate (bad word choice) with no movement by this very small amount. This can make the axis and/or joint appear its beyond a soft-limit. For instance, when I zero the DRO will remain "zero" but the "-" will flash on and off. Again, maybe all this has been addressed.

Additionally, I have found incorrect and inaccurate details regarding the setup of absolute encoders and how LCNC handles them in both document and forum searches. I am more than willing to contribute back, but "guidance" would be more helpful.

Lastly, tommylight  Thanks for all your efforts as a moderator; it's a thankless task.

On my opinion, better not to use USB communication. I had USB joystic connected to CNC, if USB lost communication - need to restart linuxcnc to access it one more time. USB - it's not for device control - only for file exchange - on my opinion.

Linux cnc supports EtherCAT interface. Try to make your device with communication protocol as EtherCAT slave. It will be more professional device in this case.

I have a DIY RouterMill that I've been fighting with for many years. I recently ditched MACH3 and paraports for the MESA 6i25 <=> 7i76u combo.
After flashing the 6i25 with the 5i25/7i76u x 2 bitfile and updating LCNC to 2.94 and configuring with PNCConf, all of the steppers worked as expected and were tuned for optimum movements for my machine. Turning my attention to the INPUTS, based on what I understand from the docs, the INPUTS are sinking so I configured the machine with all INPUTS as follows:

VF(24v) -> switch(NC) -> 7i76.0.0.input_nn

After starting LCNC, I notice that the ESTOP was triggered but, the button was not closed. Checking the INPUT pins with halshow, I could see that the board was showing all INPUTS as TRUE, therefore I changes all of the INPUTS to input-nn-not and restarted LCNC. Now all of the INPUTS seemed to respond correctly. When I attempted a HOME_ALL, the Z moved to positive, so I reconfigured it to home negative with PNCConf. That worked and after more reading and adjusting of some parameters, I got the Z homing correctly backing off the trigger position by .050 in.  Then I directed my attention to X.  However, I had to adjust a few more parameters for the X axis then restarted LCNC. *)#$!! All of the inputs had switched and were now reporting as TRUE. Frustrated I changed all INPUTS back to input-00 and restarted LCNC. With this session I was able to get both the Z and X axes to home correctly, however, Y was now the problem child as it would not back off the trigger position. After several attempts I finally decided to swap DIR-/DIR+ at the microstepper so the Y config was exactly as the X config. (My Y axis is at the back of my machine so I had reversed the motor in the config for correct movement). After making the change and while running PNCConf I confirmed that the Y axis was now responding correctly then proceeded to resume verifying  the HOME ALL function, The attempt failed, so I tweaked the HOME parameters but, when I restarted LCNC all of the INPUTS had again switched their state (*)#$!!,*)#$!!). More bizarre was that now no matter how I set the PROBE input (input-nn or input-nn-not) the halshow remained the same.  After several additional restarts, the input pins again flipped the input state.

At this point I'm half inclined to suspect the 7i76 board as it has one INPUT, input-04, that is always stuck in the same status in halshow much as the PROBE input is now responding.

If anyone has any ideas that I can try, I would greatly appreciated the support.

Regards,
Stephen

I use Gmail just like Todd, and there are no emails in any folder.