Advanced Search

Not sure but this looks odd, wouldn't you want to calculate sharpness first to update kappa and then theta?:
 

 

Oh, and also, the GEOMETRY = XYZBC, no need for that -Y.

OK, alright, for anyone who finds this, and has the same cognitive block I did, here's my answer and hopefully it helps you.

Right hand rule: (as Rob has pointed out many times), um rules: so...
Top of Machine is low negative, and gets more negative as you go down.
Left of machine is zero, and gets more positive as you go right
Back of machine is High Positive, and gets more negative as you come forward (this was my Y axis and my first sticking point)

Depending on wiring and screw shafts and belts and whatever, you have to determine which way to move your axis so that it obeys that convention.
A test with writing will help, since it will be mirrored in some direction if you have your motors going the wrong way.
See: ~/linuxcnc/nc_files/examples/3dtest.ngc and /usr/share/axis/images/axis.ngc

To reverse a motor/axis (I needed to do this to get myself right: I was 'writing' the logo mirror-backwards in Y) the easiest thing is to go to your .ini file, to the [JOINT_n] for your axis, and reverse the sign on STEP_SCALE. (There are other ways, reversing wiring, etc, but this worked for me and is easy to undo and all my wiring was otherwise identical, so I preferred a software solution.)

Then you need to worry about homing. If you had it working before (as I did) then you'll need to reverse the signs on HOME_SEARCH_VEL and HOME_LATCH_VEL (Mine went from positive to negative).

Finally, and this is the one that bent me a bit. (And I see Aciera has jumped in to help me while I'm writing this, and I thank him very much, but I don't think the answer is quite right for me... I tried that and it wasn't very good.)

You have to make sure you're honoring the right-hand-rule, which means whereever your sensor is that trips to signal your axis has reached it during homeing, should be numbered accordingly.

The part I had to wrap my brain around was that in my case, this means it's:

I was trying all kinds of HOME_OFFSET settings waaay too close to zero.

Now my machine red lines are correct, and loaded files show inside the machine, and all the axes move the way they're supposed to.

It even 'air carves' LinuxCNC as pretty as can be.

Thank you thank you Aciera!

Cheers everyone!

 
 

Did you ever end up finishing this project?

It can be done pretty easily with external components.
Feed 24V using the unused leads in the CAT cable, and a step-down unit from 24V to 5V and there you have it.
At the prototype stage this simple cable will work. And  24V stepdown converter (board needs 5V) is dirt cheap.
 
 

BTW the photo-diode opens so good that I don't need a torch-on relay, but can be had if needed.

Dear tommylight,
I sincerely apologize for taking your support for granted without doing my own due diligence, so I went back and read the entire thread from start to finish to enhance my understanding a bit better before asking anything else. Unfortunately, I am a student with little to no prior experience within this field (mesa, linuxcnc, machinery). While I understand everyone here is quite busy and their time is invaluable, I would wholeheartedly appreciate some guidance from experts like yourself. I also spent a lot of time reviewing the wiring diagram as well as physically cross-referencing things with the actual machine, which helped my insight quite a lot, however, I also have ended up with many many more questions.

1) I have confirmed how the ATC operates, it uses the same 4-switch grayscale sensor within the gearbox to check in position as well as indexing, however, the actual motion requires the spindle to be 'straight' so that the tool ends can slide into a locking area, at first I expected this to be done by the absolute encoder, since there's no sensors or anything for reference gtgrips in the spindle system, however after checking the wiring and the DARC manuals, they are listed as 'resolver' cables, specifically 2 pole resolvers which as far as I have seen, cannot perform this function, please let me know if otherwise.

2) the same is true for ALL the axis motors, except the long X axis, (no short X axis in this machine, 2001/2003 model sbz 130/01, but everything else looks the same as yours ), but only the X axis I have found some sort of spring based limit switch that can be seen for referencing trips, but I have also reason to believe these might just be for emergency and is it possible these resolvers can be used as absolute encoder functions (no homing).

3) after some research into Linuxcnc and mesa cards configuration, I have understood the choice of your mesa cards (input cards, output, analog control for the servos, FGPA card, connector, etc) however I would like to know how compatible your set of files/card combination would be in this case for me.

Once again I am deeply sorry for my earlier ignorance, it is simply my lack of experience, and I would really appreciate some guidance in these questions as well as my future doubts, and I will do my best to be vigilant in my own education on the matter. 

when I set it without the -Y, movement in the display is mirrored in Y

This indicates a wrong machine setup. when you jog in the positive Y direction does the tool move toward the back of the table (on the real machine not the screen)?

My Y home sensor is in the back,

In this case your Y-axis and joint limits should be:

Argh!

Before anyone looks at this, it seems I do still have myself backwards.

I'm sure once I put my pants on front-wise I'll be out of the Looking Glass on this one.

 

Argh!

Before anyone looks at this, it seems I do still have myself backwards.

I'm sure once I put my pants on front-wise I'll be out of the Looking Glass on this one.

spam removed

No, I set it on one axis I was testing. Should I set it on all axes?

Thanks Rob. I'll get the 7C81 when it comes back in stock.

I thought that I saw somewhere that the 7C81 is now supported in the PNC config Wizard. I could easily be wrong though.

Thanks.

I was asked to post in this thread about a problem I encountered with installing the official LinuxCNC image for the Raspberry Pi 4b. 

The issue I had was once the image was burned to the SD and booted the monitor that I have for the RPi was skewed on the login screen. It looked like the picture below. You could make out what it was showing and could log in and it would take you to the desktop but it was also skewed. You could make out what was there and navigate to the display settings, change the resolution, and get it working, but the changes were not persistent. Everytime the RPi booted it would revert back to the skewed resolution.

It was suggested that the HDMI cable could be at fault, and this is a good suggestion. I did try a couple different HDMI cables with the same results. 

I tried a lot of things from internet searches about this problem, but nothing seemed to work, but I finally found a clue from one post in the internet that was hard to find. I wound up changing several things in the config.txt file in the top level directory of the SD card. I used a Windows laptop to make the changes. Once I had it working, I reversed the changes one by one to see which change was the one that actually fixed it. Here is what I found:

In config.txt you will find this section in there with notes about what I changed to fix it:
[pi4]
dtoverlay=vc4-kms-v3d,cma-512              Comment out this line
#dtoverlay=vc4-kms-v3d-pi4
#dtoverlay=vc4-fkms-v3d                          Uncomment this line
max_framebuffers=2
arm_boost=1
#disable_fw_kms_setup=1

As I understand it this forces the use of an older display driver.

I believe this problem was due to an incompatability between the display I was using (Cheap Chinese 10 display) and the newest driver on the RPi. Forcing it to use the older driver got it working perfectly.

BTW, I also tried the same SD card on my son's RPi 5 and had no problems even with the unmodified config.txt.

Incidentally, the display I was using is a cheap one I use as a second display when I travel for work. I bought cheap because it is likely to get busted up in luggage some day. For my final LinuxCNC display I will be using a different touch screen display. Hopefully that one will work well.

I hope this will be helpful to anyone who may encounter the same problem.

The 7c81 will be fine. The only issue the wizzard doesn't support the 7c81 but you can pick a 5i25 in the wizzard and edit the files after to suit, just replace 5i25 with 7c81 and change the loading of the driver to suit.

I actually made a "homemade clone" of a 7c81 using an FPGA board from Aliexpress and some custom boards. The only difficult part was modding the hostmot2 sources to suit. Pete from Mesa was helpful with this project and I'm very appreciative of the support he give on these projects. My reason for going this way is it was a cheaper option, freight to Australia almost doubles the price, and I was looking for a "challenge". BTW the same hardware will work with the Linuxcnc-RIO project, and with the addition on a Wiznet ethernet module it allows for an ethernet option with the Linuxcnc-RIO project but not with the standard hostmot2 firmware (that would require some work on the Linuxcnc side and the FPGA side)
github.com/ozzyrob/Linuxcnc-FPGA

When using software stepping the upper limit will depend on the base thread period you can work with on the RPi4.

All The Best
Rob

Sorry that should be
The editor makes it a pita to edit posts.