Advanced Search

I downloaded the iso and ran the live cd and there seems to be a problem with xfce and running gdebi from the file manager. I had no problem installing Mesa CT using a terminal and the following command. Also seems xfce is broken if you try and launch a terminal using the keyboard with Ctrl Alt t. Must be a reason I don't use xfce and prefer Mate.
JT

Adding this got me persistent tool in spindle, but its still not remembering the carousel. I'll try to dig more into EMCIO see if I'm missing something

@Lcvette,

Is the G9 going to specify only those section where G64 is located?
For automation the G9 will be used to solve a gcode program using G64 P&Q values.
Then multiple G64 commands with different values in one gcode file are ok.
That's what is mentioned earlyer to deal with.

@All,
I have done a discovery. Was digging into how nurbs are processed. It turns out they are
loaded into the trajectory planner as a x number of arcs. So in fact the nurbs are transformed into
tiny arc segments.

I think it's better to interpolate nurbs, splines, etc by the trajectory planner itself.
This avoids tiny segments and is just more logical to do?

My plan is to certainly interpolate the tri-clothoids directly in the trajectory planner. So we add
a function : tpAddClothoids to this. And maybe also tpAddNurbs & tpAddCubicSpline etc.
It's also a idea to pass a general primitive like: tpAddItem(enum type); Where we just can load what
we want without messing with all kind of code.

I finally found how the interpreter rs274 is given the gcode to the realtime part of lcnc.

The interpreter is called by init(), read() etc. No problem.
Then the weird thing is, It calls function's that don't excists in the interpreter source itself.
That was the confusing part. I suspect you could name this callback functions.

The interpreter code will not compile without external program that has several interpreter functions declared.
For example, this function is not in the interpreter code :But it is called by the interpreter.

Then the milltask.so is the chain between the interpreter and the hal realtime part.
The hal realtime part is motmod.so, here it sends motion commands to the trajectory planner like : tpAddLine().. etc.

The interpreter has also a python interface, so the lcnc gui's can get the data to draw the opengl gremlin gcode.

Notes:
 

The plan now is to add a callback function to the interpreter for test  :
void TRI_CLOTHOID(){}
This then has to be added into the source up to the trajectory planner. Let's try this.

Thank you very much for your suggestion - in your words, that's more or less what I've been trying to get at since the beginning of this thread.

I'll try to show you one more time what helps me, perhaps simply listed here in full, if the PDF sent above is not meaningful enough?

As a beginner, I can't possibly ask questions if I don't know how to ask them so that you understand me. Unfortunately, this still applies to the next steps. Of course I have learnt something since the start of this thread on 16th April - so I hope I can follow your procedure?

I would like to mention, for example, that I wanted to know from the beginning to what extent the MESA/LinuxCNC combination is a Plug and Play System. 7 weeks of experience in this thread have shown me that it is not a plug and play system.
It is still not clear to me to what extent the software recognises the contacts?

1. in the attachment you can see the files created with PncConf HAL/INI. However, I can only create the files as "close" to my requirements as my knowledge allows. Apart from that, I am very inquisitive!

2. as I have already tried to explain in my posts and tried to show in the latest post with video, this is exactly what you are talking about ...
I have gaps in my knowledge, or rather I can't get any further because I don't know which ones.
to the written down, a link to a video which shows exactly the working sequence below.

www.dropbox.com/scl/fi/zvlnvbh0shn8yzmmg...c9t&st=y371x166&dl=0

www.dropbox.com/scl/fi/j11dlftomcir853uv...h82&st=rkvnukan&dl=0

When I open the machine with this HAL/INI file:

I start the CNC machine and ...
- sometimes errors
- sometimes no errors
When errors appear ...
- I close the machine
- open the machine again until no more errors appear (the errors are secondary for me at the moment, because I would like to assign the correct features from the pulldown menus of the PncConf to the corresponding contacts of the 7i76)
If no errors appear ...
- I press the emergency stop
- I switch on the machine with a mouse click

Reference runs of the axes for a Cartesian axis display:
I click on reference runs, then follows ...
- Reference run of the Z axis in direction minus, instead of plus
- the reference run until an error appears (I can't get any further)

What do I want to know about the Reference runs?
why doesn't the machine show me the Cartesian axis view after the click before the axes start moving? (motors 1 and 2 before the Y gantry axis)
why does Z move to Z- and not Z+ for the reference run? (the same applies to X and Y if I move them individually)

What I want to know about the settings* in PncConf? *by settings I mean the individual selection options in the pull-down menus
Initial situation:
My current 4 PNP Sensors are limit and reference switches in one (if more sensors are needed I can upgrade later)
- 1x for the X axis
- 2x for the Y axis (1x for regular use 1x as a reserve in case the regular one is defective)

My facts and questions:
- the X and Z axis sensors are recognised and the servos stop at the PNP sensor
- for each axis "both end and reference position" are selected in the pull-down menu (is that correct?)

Where can I change the direction of travel from - to +?
Which features from the pull-down menus do I need for ...

Mesa 7i76 TB 6 (please also see Excel PDF in the post above)
Output 0
Output 1

Mesa 7i76 TB 5
Input 20
Input 21
Input 22
Input 23
Input 24
Input 25
Input 26
Input 28
Input 29
Output 8
Output 9
Output 10
Output 11

Mesa 7i76 TB4
Spindle -
Spindle SPM VDC
Spindle ENA -
Spindle ENA +
Spindle Dir -
Spindle Dir +

i now hope that this final list is simple and easy to understand? Otherwise I don't know how I could present it differently in this way and hope that you will ask questions if anything is unclear?

You'd have to implement a multipole switch, one pole for each signal that needs swapping over.

Or if you only need to switch low current, a demultiplexer could be used for inputs and a multiplexer for outputs, but that's going require you designing a circuit.

Open collector transistors are a possibility but either way its going to require some work.

Regarding volatile/persistent parameters see:
linuxcnc.org/docs/html/gcode/overview.ht...:numbered-parameters

Hi,

which COMP file are you using? are you runninr 2.8 or 2.9?

moving was basically working, but that needs to assing the right signals to the pins of pokeys.comp file.

regarding homing i'm still stuck in the status that i posted in the previous comment.

Thanks for that link.  If I understand that thread correctly, LCNC is trying to continue to accelerate the spindle to infinite as the radius approaches zero, although there is a MAX_OUTPUT = 2000 in the ini file.

I need to a Dxxx value to my PP to limit it.
I had set my work and tool offsets, so X0 was (should have been) the center of rotation.

It is not the old Gmoccapy issue at the bottom of that thread, as that bug was squashed by Norbert many versions ago.
Cheers,
mark

Thanks for the offer. I just received a care package with three parting tool holders in it, so I should be good for the next two attempted parting moves :/

Yeah, I know, but I am on a welding trip at the moment.

I'm not really familiar with ATC setup but I think the tool location is actually tracked in the tool table rather than with parameters.

If this is this a 'random' toolchanger you may want to try to add this to the [EMCIO] section of your .ini file:

RANDOM_TOOLCHANGER = 1

linuxcnc.org/docs/html/config/ini-config.html

there are also debian packages now:

multixmedia.org/debian-packages/

download and install with:

apt-get install python3-viaconstructor_*.deb

no pip is needed

Counterweight is the best solution, gas springs do work but require a lot of testing and adjusting and must have much more usable travel than the axis it is on as it does stiffen a lot near the end of the travel.
Brake is the worst solution as the whole weight of the axis must be countered by the servo drive/motor causing load all the time while the machine is enabled, and inevitably will drop a bit every time the machine is enabled and disabled.
E-stop should always engage brakes, but no worries about it, when the power is cut to the brakes they will lock the motor. Brakes should be controlled by the "machine is enabled" pin as that will engage them when there is a drive error or joint following error, and when e-stop is active.

This gives me some things to think about for awhile. I'm very grateful for everyone's comments and suggestions and the time they took to post here for me. It's very kind.

I'll have to see about getting the proper PNP switch or the proper resistor somewhere. If those switches have a resistor and they work then maybe having two might not be a good idea? I'm not sure, but that's what my dad thought. I do think doing it right would be ideal though. So thank you to everyone for providing all of the information about them. It's super helpful.

The cost isn't really an issue, their price is fairly reasonable if they last, but unfortunately it seems I can't get those breaks delivered to Canada so maybe I can find them somewhere that will deliver to me or at least something like them, now that I know exactly what I'm looking for. In fact, I did a search and noticed there are actually similar ones on the Teknic website here:

teknic.com/products/spring-applied-power...rakes/NEMA-23-brake/

There are a couple things that concern me though which might help me choose between these types of breaks or the counterweight or gas spring breaks. I don't know if those Teknic breaks are as powerful as the other ones and maybe it doesn't matter, maybe they would be fine. I don't know how much force they have to hold so I suppose the first order of business is figuring out how to measure how much force it has to hold to know which break to get. I'm sure there are calculations and math and whatnot involved which I'm no good at so I'll try to do some research and see if it works out.

Another thing I'm curious about is when doing an e-stop if it uses the break and if there is a way to disable that or maybe that's something I would actually have to enable in the first place and it's disabled by default because I have to connect pins in hal. I only want to apply the break when the machine loses all power and not on an e-stop so that it doesn't wear out the break which I'm guessing is a thing. So I'm wondering if maybe there is some way to set it so that it doesn't use the break in an e-stop and only when the machine loses power or if it's just going to be like that by default.

Thank you everyone! This is very valuable information and I really appreciate everyone's time. This is really great. What a nice community. It's all starting to make more sense now with everyone's great knowledge being imparted onto me. Thank you!

Oh, everything is fine with Z.
I run out in X and Y. (Red on the picture)
Y83.8 and X152.4

The fun part is, when i "touch" G54 to another position, it sets the origin perfectly fine, as every time.
But Y83.8 and X152.4 just stays red, and i get an error, if i try to run the gode.

I'd add a step to move the axis over the travel range and compare the stepgen distance to that reported by the encoder. This can catch encoder misalignment.

Next run a collection gcode script and plot stepgen vs encoder (both directions). This can confirm your encoder alignment and measure backlash over the travel range. If you see weird things in the plots figure them out (before enabling encoder feedback which can complicate funding problems) weird things can include periodic wiggles from bent or misaligned shafts, different slopes from the encoder both parallel to motion, excessive backlash from loose bearings, etc

Encoders can be great especially for faulting before scrapping a part, but they should be carefully verified.