Velocity tuning of YY2 gantry

Todd,

Thank you for your response and time to look over the config.
I'm guessing I had more then one of the same configs open when I saved out the wrong one reverting to the wrong scale. I just recalibrated and it's within .001" over 36 inches.
Thanks for the heads up on noise. The old control worked with current wiring but I don't like everything going through one big conduit. Horrible idea. Meaning VFD power to spindle, servo power, encoders and limits homes etc in close proximity. I did ensure all signal drains are connected to one star ground and only on the cabinet end.
Now I did come upon an issue with different ground potentials of the PC and control cabinet. PC is now powered off same source and has same ground potential. I would assume that could cause an issue. Running a part right now and hope it will not error out.
I will load the scope and recheck signals again at some point. Can I capture/save a screenshot in linux? I think gimp is loaded on my version. I wish halscope had a save to image feature.

Yes, Linux can do screen shots. But it depends on what software you have installed. What Linux version do you have (distro, destop...)?

For example if you are running the old Wheezy Linuxcnc ISO, pull down from the menu bar Applications>Accessories>Screenshot.

Also if it helps you can try adjusting the encoder filter settings of the Mesa card. What the ideal settings might be for your machine will be dependent on a combination of your encoder resolution, maximum acceleration, and maximum velocity.

I think it's Debian, Stretch, 2.8, with rt-preempt. I'll have to double check when I'm back at the machine. Good news is it ran an 8 hr program without a problem!
I now have a soft limit question. When I park the B or C rotary axis at it's soft limit I get en error that I'm on my soft limit. (It may have rounded up a small value past the soft limit, don't remember exact error message, maybe past soft limit) I don't get that message if I travel to the extents of my linear axes. Is there a reason for that? In other words, I can park the xyz at the end of travel but not the rotary. Also, during homing, if the home switch were not detected, would a rotary joint stop moving once it traveled past it's assumed soft limits or will it try to rotate say past 360 degrees looking for the home trigger? I can't really test this on this machine as it may wrap the wiring. I need some ideas on how to handle the rotary safeties.
I currently have to manually position the joint to location before home switch trip. If end user accidentally shuts down machine in wrong position, rotary may not find home correctly.

if the home switch were not detected, would a rotary joint stop moving once it traveled past it's assumed soft limits or will it try to rotate say past 360 degrees looking for the home trigger? I can't really test this on this machine as it may wrap the wiring. I need some ideas on how to handle the rotary safeties.
I currently have to manually position the joint to location before home switch trip. If end user accidentally shuts down machine in wrong position, rotary may not find home correctly.

Well, it got tested by the end user. Appears rotary will try to seek home switch past the soft limit values. Is there a way to implement a rotary joint homing feature that stops homing if switch is not found within the soft limit boundaries? This would help prevent a rotary from wrapping all the way around if parked inadvertently past the switch.

The problem is before the joint is homed, Linuxcnc doesn't know where the soft limit is/should be. You might need to consider using an absolute encoder system.

I understand that but ABS is out of the question on this build.
Why can't a joint be made to start count before home is found? It could compare that count to an ini limit setting and if found to have exceeded it, pause and offer a warning. Then allow joint manual jogging to re-position to location before the switch and re-home to establish it's true position. This could be an added safety no?