Advanced Search

                             

I bow to the Great Cornholio!

A Tip of the Hat to you.

Is there any issue with using the RTAI kernel on installations that boot via urging as opposed to BIOS or so called Legacy ?

I was just thinking of GRUB, but I guess grub initially gets installed with a kernel that mounts efivars and after that it’s plain sailing. Would there be an issue if Debian decides to update grub package and that update is done on a system that boots via uefi?
Would pinning the grub package to not update prove beneficial ?

Or have I put my foot in my mouth ?

It’s a shame that the various Ethernet modules about that use the same PHY as the arty, DP84xxx, only bring out one tx & one rx signal.
I’ve been slowly looking the W5500 code to see if I could see anything that jumps out that points to connection loss.
I’ve tried using a simple board similar to I’ve used when experimenting with a 7c81 copy, no dupont jumpers acting like antennas and reducing the divider to reduce the spi clock speed all to no avail. I’ve got 2 of the waveshare type boards and one of the Wiznet ones that are basically just the size of the RJ45 connector. Same results with both.
I don’t know why I’m so intrigued in getting it working, the UDP to SPI bridge works fine with my RPi 5 but not so with the RPi4.

Just one thing to consider a USB connected device is not “realtime” and is at the mercy of all the delays, latency and disconnection and reconnection that comes with it.
Where as the 7i73 is realtime, rock solid and I’ve never seen it lose a connection.
Another great thing is due to the use of Cat5 cable for connection it can be mounted anywhere.
Unless you design your device to use native USB, which I can only recall one project that did ie: it enumerates as a HID device, you’ll basically be operating at serial port speeds rather than 2.5M bits a second. This may not be an issue depending on packet size.

Basically what it boils down to a 7i73 pendant is going to be more responsive than a USB based one.

Now there is always the possibility of implementing the smart serial protocol into your device.

I presume that can be any plane in space (ie it does not have to be XY XZ or YZ)?
Yes, any plane.

If that is correct we can use the plane that is defined by the tool orientation vector and the corresponding point (TA knot) and project the two TA line segments (ie the one that comes from the previous TA knot and the one that goes to the next TA knot) onto that plane. Then we have the projected lines on a common plane and we can use the clothoids library to create a G2 continuous fillet.
Of course we would need to do this for all TA knots and their respective planes in space.
Yes that is correct. Three ta knot's can create a plane. On this plane we could record the tcp-ta intersection along the plane.
Maybe this is the best solution, we have to test it i think.

[edit]
Ok, I think we can forget this idea as this will still not create 3D clothoid curves but only 2D.
[/edit]
It will create a 2d clothoid in 3d space, it's valid as long it draw's the clothoid on a 3d plane with the current clothoid lib as is.

Isn't this the same situation as you would have when adding a fillet between a straight line segment and a helix segment in Gcode (except of course the helix segment would be oriented to XY, XZ or YZ plane)?
For now it isn't valid to create clothoid fillet on a helix. I didn't told it yet. It would be valid if clothoid is 3d.
It would be valid if fillet is of type 3d spline.

How do you handle  line-3d_arc segment corners in tool paths?
I think you mean, for using clothoids valid combinations are line-arc, arc-line, arc-arc as long as they are on the same plane.

If the clothoid library can only create 2d curves then the only solution I see would be to approximate all arcs with a polyline. Which is exactly what 5axis CAM output seems to do.
With this approach there would only be line-line segment corners.
The situation we have now is a 3d arc to 3d arc connection, both arc's are on exotic plane position. non xy,xz etc.
So this would not happen in normal gcode. This happens because we have a tooldir path recorded.
For normal gcode, i think the clothoid can cover 95%-100% of the fillets.

Things left to investegate:
1. We can test your plane idea using the 2 ta knots as plane.
2. We can test using 3d spline fillets, for our tooldir path.
3. We can invest more time in creating 3d clothoids to cover all exeptions.



 

I could see skipping the angular when there are no rotary axes. In simultaneous 4 and 5 axis work the majority of motion commands have angular components also.
I am just trying to understand the mindset of why the code is structured like it is.

Do you have the part number of the drives?
Can you get a picture of the drive connections

(The drives are the modules with the aluminum heat sinks)

Pinned.
Thank you.

you cutoff the important section showing what the error is, the debug section.

need more information on installation, system

Just FYI, for LCNC with LPT cards the lowest latency jitter is typically reached using RTAI.

The latest RTAI debs for 2.9 may be found here:
forum.linuxcnc.org/9-installing-linuxcnc...ng-rtai-debs-for-2-9

Does lspci show the parallel port I/O  addresses as enabled?
(there is a possibly identical issue is a recent thread)

forum.linuxcnc.org/9-installing-linuxcnc...rallel-port?start=10

When I ran Axis on a very similar machine a number of years ago I never saw or heard about HAL.

That is the idea of the Pncconf and Stepconf tools. It should create all HAL connections for you, provided the user entered the correct information of course. Once everything runs you should not need to touch any of the config files again.

andypugh wrote:

Keystrokes are a pretty bad way to interface to LinuxCNC.

Can I suggest that you consider a Mesa 7i73 ? That can interface the control panel directly into the realtime layer of LinuxCNC.
store.mesanet.com/index.php?route=produc...oduct&product_id=116

It's probably not as much fun as your custom board, but it will work out of the box.

There is a strange HAL component that I wrote that might help if you choose to go your own way. It's strange because it does two completely different things in one component.
linuxcnc.org/docs/stable/html/man/man9/matrix_kb.9.html
The side that might help you is converting scancodes into HAL pins.


 

Andy,
I'm exploring the various ways to get data to and from Linux to my board. I already have hard wires connections for EStop, and machine power.

Focusing for the moment on data from my board to Linux I made a table of the 50 or so button presses that I would need to send, and from playing with a Axis and a regular keyboard using showkey it seems there is a hot key or key sequence that covers all 50 buttons that I anticipate using. There are a few anomalies that requires sending two key strokes or in the case of the jog increment keeping track of how many I's or shift- I's were sent so that has the potential to get out of sync, but other than that it seems really straightforward to just have my little on board uC scan my buttons and send the key or key sequences based on the keycode in the table below.

I found the table "most Common Keyboard Shortcuts" in the Axis documentation.
Do you know if there are additional commands documented elsewhere?

When you say it's a pretty bad idea to do this perhaps there is something I have overlooked?.

The Mesa 7i73 is interesting, but probably not a good fit for this project for a couple of reasons:
1) Physically if mounted as a daughter board would make the overall board depth thicker than I want.
2) I want to use the little touchscreen as I have used it before and it allows easy GUI enhancement in the future for things I can't anticipate now.

Assuming this will work for data to Linux, I now need to put my thinking cap on to figure out how to best get the Linux status data I would like to use back to my board so I can optimize the GUI. Jog Increment value would be a good start, I need to make a list.