Advanced Search

Hi again,

i got it, there was an indentation error, fixed it also changed self.w.gcodegraphics.colors = (1.0, 1.0, 1.0) to self.w.gcodegraphics.color = (100, 100, 100) so i have a grid on perspective view now

Thanks Chris

Thanks for the detailed reply Chris,

I disabled all the lines i added to the code and added some of your code under init_widgets() function and put the rest where other functions or patches are defined, when i run the linuxCNC i got the attached error, did i miss something?

So in its new home now.

Guy has upgraded to 2.9.3.

Now the arc ok only works once per job. So if it’s got 4 cuts, arc ok and thc works on the first cut, but after this it fails out until you select ignore arc ok.

Doesn’t happen on my new machine setup the same.

Heading there now to check it out.

Any ideas?

Thanks, I will try to set it up the same way with both sensors needing to be high for homing.

I've made a little setup with optical sensors and for indexing just added a "flag" to my drive wheel.
The homing sensor and flag are below the pocket which is the pickup location for the spindle, as it just happened to be a good spot.

 

 
 

I managed to do so far, but when I give the command
sudo pyocd flash remora-rt1052-3.1.3.bin --target mimxrt1050_quadspi
nothing happens, it doesn't compile for the nvem board, but if I give the command pyocd list the address appears

Here the initial last count variable:
github.com/LinuxCNC/linuxcnc/blob/master...ragon_handler.py#L95

here you see how it calculates the count difference:
github.com/LinuxCNC/linuxcnc/blob/master...gon_handler.py#L1927

here it decides up or down based on the calculated difference:
github.com/LinuxCNC/linuxcnc/blob/master...gon_handler.py#L1956

At the end of the function the last count is set:
github.com/LinuxCNC/linuxcnc/blob/master...gon_handler.py#L1986

Sorry for cryptic message - I am away from home for work.
I did not know that QtPlasmac was patched to show a grid in P view - those plasma guys are very crafty!
I also didn't realize QtDragon had no builtin way to show grids

(I assume your gcode graphics widget is called gcodegraphics in designer)

To get XYZ grids to show you must set a grid size:
self.w.gcodegraphics.grid_size = 1
setting the grid color is possible (Red,green,blue):
self.w.gcodegraphics.colors = (1.0, 1.0, 1.0)
add those to bottom of  init_widgets() function.

to get grid in perspective too require patching.

add to bottom of  init_widgets() function:I think I should modify the underlaying code so the patching is not necessary - on the todo list.

I think maybe you don't understand how rigid tapping works.


When rigid tapping, the Z axis motion is synchronized (geared basically)
to the spindle rotation, the synchronized motion is continuous through
the downstroke, spindle reversal and upstroke. Any pause that interferes
with this "gearing" will break taps.

hi there,

I have a long talk with gentelmen from the beckhoff which are talking that 2ms is for them limit of RT control ... I am experimenting with the 7 axis over profibus and there is latency 1336us, but I have not tested them ever... I have setted them to 2ms 

I think for 3 o 4 axis it should be less then 1ms in the optimalized profibus cycle with equidistant mode active... I am running old metronix servopacks over speed loop... Everything works well even homing procedure but I think it is not for extremly precise machines probably I will facing the limits in the future but that servopacks was for 40bugs at locat market place

I have configure CanOpen, profibus, profinet over ethercat too but profinet have terrible delay 4ms which are not enough for anything ... or use the IRT profinet with 31.25us latency(there is limitation of 5 or 6 device on the network) but you will need special interface from continental which is only dealer of them

My machine is running at mesa 7i77 + linear scales, next running kollmorgen packs at 250us + linear scales, next nidec stuff too at 250us{not all stuff integrated as driver build in probing} and now I am experimenting with profibus ... 

S120 is profi solution on 31.25us drivecliQ bus but it is soo soo expensive ... EtherCAT should runs at 62.5us but need native stuff and I have never tested them that fast... probably there will be limitations of lcnc latency hw itself

regards 

I am in North Carolina in the USA, you are thinking of Joco in NZ..lol

yes you want to use the geneva pin for the pocket index so its in the locked position. for homing, you could configure it a few ways, but typically i would use the home switch + the index switch so when homed it will be in the locked position of pocket #1. I was planning on using the same dumb motor step generator so please let me know how it works out for you. here is how my home/index is setup on my little atc build:

 

yes because of all the confusion previously of how to calculate it I made it specific to the subroutine used to set it. not sure if I can make it both manually enterable and via subroutine easily or not. will have to take a look when i have some time again. I have been a bit covered up recently but hope in the next week or two to have some more time to work on the ui.

It is a issue in the component, it happened before where another USB ID for the shuttle was left out of the code and Andypugh fixed the code adding the missing ID. That was 5 years ago. The 011 shuttle ID was not added and is still not provided for in the code even though it is a valid ID for some shuttle pro devices.

Here is where Andy changed the code to add one of the missing USB id's
github.com/LinuxCNC/linuxcnc/issues/702

The shuttle docs list 3 USB codes for use in addding a rule but the 011 code is not mentioned.

For now I connected a shuttlexpress I had and that works fine (its ID is 0020 which is in theShuttle.1 source code)

Do not bother to much with the details for now, assume standard stuff, make some test configs, do some measuring to make sure the axis moves the exact distance as commanded, let it rip!
You can make as many configs as you like for the same machine, you can even edit the scale and some other stuff while LinuxCNC is running and save from there, using the "calibration" from the "machine" menu.
It would help to know the exact screw pitch, so mark the screw and the nut with a sharpie, turn the screw several times, measure, enter that in the wizard.

Google suggests that they are both 1.8 degree (200 steps per revolution) motors, so stepconf's default values should be fine...