Advanced Search

Mo pichurs... for your enjoyment (or hate, you do you...)

 
 
 

The atc mounting arms are just pure brute force right now. I need to refine them be a little lighter and a lot less expensive.

I noticed the ENDSUB doesn't match the SUB in tool-length-reset.

Alllllmost there.

 

Hi Andy,
I believe that the issue I'm describing is exactly the one here:
github.com/LinuxCNC/linuxcnc/issues/2926

The last comment from that issue was you asking about the motion.motion-type following motion.probe-input going high.
I've looked in the halscope and it does seem that motion.motion-type remains at a value of 5 (Probing) until deceleration is completed, at which point the motion-type goes directly to 0 (Idle). So the issue isn't that the motion type resets immediately when the probe input triggers.
I was probing using just the X axis/joint 0 when I tested this.


I'll try and find out a bit more if I can.

Andy,
Thanks so much!
I had a dig through some of the motion planner, and it seems when an incremental jog is commanded by the GUI using NML, then this is the associated case in:
github.com/LinuxCNC/linuxcnc/blob/master...otion/command.c#L841

If the incremental jog is accepted, if it is a joint jog (free mode), it seems to handle all of the logic there, with the target position assigned as follows:
Whereas, if it is an axis jog (teleop mode), it will call the functionin:
github.com/LinuxCNC/linuxcnc/blob/master...c/motion/axis.c#L279
So, for both joint and axis, the way the position is assigned is essentially the same, it modifies either the value of  or  by the value of the jog incremental offset.
These would be the hal pins... which actually already exist as  and !

I thought I'd tried the axis ones already but I must've forgotten to home the sim and since I had the joint jogging pins connected as well I didn't realise I wasn't using teleop 

But yeah, the 'backlog' of incremental jog-counts is just converted into a teleop or free mode motion planner position (which explains why a backlog acts just like a continuous jog).


And, yes, I did sort of avoid saying why I was looking into this (sorry!), wanted to see if this way would work first!
I was looking at meister 's camjog widget
github.com/multigcs/riocore/blob/main/ri...ons/camjog/camjog.py
It jogs via jog-counts (which is definitely the best way to do this), but the only drawback is that it can move in a dogleg if one joint or axis takes longer than the other to reach the destination.

But, if you compare the 'jog DTG' (my test assumes both have the same max velocity) for x/y (or the joint equivalent), you can scale down the velocity of the joint/axis which has the smaller DTG according to its proportion against the joint/axis which has the larger DTG, and then use that to scale the milltask joints/axis max_vel pins.
And the other required logic is that if at least one of the joints/axes is within positional tolerance of the target position, the velocities of both the joints/axes need to be set back to 100%.

Anyway, this is sort of trying to force free or teleop mode to act like coordinated mode. It's quite similar to anglejog, actually, 
but it acts later by calculating the 'Jogging DTG' from existing counts with the same scale (from camjog) and modifying the velocities to follow the resultant instead of calculating the counts itself.
I'll try and flesh out the component a bit more now I know it works.
Also, I still can't figure out why joint jogging is still doglegging   It's not a big deal for me as long as axis jogging works but I want to know why it's not working 

 

Running (in a terminal window when LinuxCNC is running)

halcmd show all > good.txt

(when running OK) and:

halcmd show all > bad.txt

when hung

( and posting good.txt and bad.txt here )

_May_  help find the reason it's hung.

I raised this issue a couple of years ago, but then the hackspace closed for a while to move location, so looking into it had to be put on hold. I was hoping that updating linuxcnc would fix it, but if anything it got worse.

Denford 2600 Pro, linuxcnc conversion using Mesa board

So, I have two scripts which are linked to UI buttons.
The first does a spindle warmup. This consists of moving the spindle to the middle of the bed (location is arbitrary) and then running the spindle for a few minutes at an increasing speed.
The second is a tool change script, it moves the spindle front and centre, prompts the operator to change the tool and then click "continue", then moves to the front left and probes the length of the tool with a switch fixed to the bed, then moves carriage back to front centre.

So on a freshly started linuxcnc, I can run the tool change repeatedly, does exactly what is expected.

Now I run the spindle warmup, does what is expected.

But now I run a tool change again... it hangs

Toggle power off and on again from the UI, and try tool change again. It moves front and centre, prompts and waits for tool change, then moves to the front left to probe the tool length... and hangs

Also if I run a job with tool changes when it gets to the tool change the carriage moves front and centre, tool change prompt, moves front left... and hangs. Now this is actually worse than pre update, I used to be able to get through a full multi tool job without it hanging.

Configuration and script files are in this repository

github.com/londonhackspace/Denford-2600-Pro

I'm really rather stuck as to what to do next. I'm a software engineer so debugging software and systems is something I am used to, but linuxcnc is currently a bit of a black box to me. It seems that running the spindle warmup script must leave linuxcnc in a different state to when it is started, one that is somehow incompatible with the tool change script (whether this is correct functionality and the issue is my script or it is a bug in linuxcnc I don't know), but I don't know how to ascertain what is changing. How can I get useful diagnostic information?

Any pointers to how to proceed would be greatly appreciated

ATC being worked out. Its gonna be fun haha. it wont be fast like a brother cause the spindle itself is slow to clamp, but 2-3 second tool changes should be viable.

 

 

The RS-422 interfaces on the 7I85 are most commonly used
for SmartSerial I/O expansion but can be used for other RS-422
uses like absolute encoders (SSI or BISS)

Fortunately the AI stuff is so far easy to spot. There are some that I swear are paid by the word. LOL

Thank you very much for your quick reply.
The 5 serial connectors on the 7i85 (without "S") are outputs for drives with RS-422 interface, correct?

Unfortunately, your encoder code is good for MPG, but totally useless for spindle.
You have not taken into account many factors, such as a variable overflow, or a digital signal sampling too quickly.
For example, 2500 P/R encoder at 3000 rpm overflows int32_t after 72 minutes...
At the other side, low resolution encoder can produce velocity as 0,0,3 not 1,1,1...
One encoder dedicated only for spindle is a very good idea.
I know, because I wrote working and widely tested code, only for spindle control.
Read the code at github.com/tuxcnc/SpindleETH
This is for STM32 with hardware encoder support, but this is not important.

No additional hardware is needed, you simply make sure the 7I85S
is jumpered for differential mode (this is the as-shipped default)

The amount of AI content on YouTube is getting to be painful, and it's quite obvious those that put it out don't bother reviewing it......how many times do you need to hear the same phrases.

Hallo zusammen,

leider bin ich mir trotz vielem Lesen noch immer nicht sicher, wie Glasmaßstäbe mit EIA-422-Schnittstelle korrekt an Mesa-Karten (z.B. 7i85 oder 7i85S) angeschlossen werden können - wird hier ein Signalkonverter benötigt?
Wenn ja, wäre hierzu der "422ENC One channel RS-422 to TTL adapter" von Mesa geeignet?


Danke,
Gerhard