Advanced Search

I checked once more with P=1 and all other PID params = 0. Motor is soft but after half a turn it starts to resist and moves slightly back when released. Tried both ways.

Removed command-deriv and feedback-deriv connections.

Checked INI file - servothread is running at 2kHz.

About tuning under load - yes, I put the belt back on, motor is connected to machine. That is why I am nervous about this behavior.

The result I am getting now is that with jogging at 1m/min HalScope shows ferror of approximately 1 mm. I move in relatively small distances 10-20 mm, because overall travel is 150 mm (Z axis on Biesse machines usually have small distance of travel). And occasionaly at the start of the jog move I get runaway. I have made it to 3rd step of trying to add FF2. And I am trying really small values (P=1 and D=1.2, so I tried FF2=0.002). The feeling is that too much of FF2 cause the runaway. Does it make sense? With FF2=0 when adjusting D term I could make more than 10 jog moves and not get a runaway. Add FF2 = 0.01 and immediate runaway. Change to FF2=0.0001 and was fine. FF2=0.002 and immediate runaway. Could be pure coincidence, I have no idea.

I have set ferror limit to 5 mm and connected pid.2.enable to halui.machine.is-on so it gets disabled when ferror limit is tripped so I have managed to avoid any damage.

Any idea where to look? Should I search for flashdrive to get the config files and post them here?

stable is locked for the moment, any fixes will be done in the develop branch which pulls from the latest main branch when building, so try there for your updates. we are going to leave stable as is for several more weeks to give everyone a chance to succesully migrate to the develop branch on their own time line since a transition requires some heavy configuration work and we do not want to interupt anyones work flow unexpectedly.

If you get 0V/5V at the Mesa terminals, there is nothing wrong with Mesa nor LinuxCNC, so check the wiring and the controller, usually reversed dir pins on controller connector or wrong pin.
Sherline used some strange pin setup ...

Another wrench in the machine:
Mesa 7i73, RS422 use differential signaling, pretty sure there is no serial that can do that, but still could be done using some line drivers, that implies using intermediary boards, lots of wiring mess, ...
Normal serial ports do 115K as Cornholio mentined, ESP32 can do much more through USB to serial using it's built in whatever it uses.
Did anyone check if Mesa 7i73 can be made to communicate at lower speeds?
Aaaand arduino jumps in...
Do you have a 7i93 mentioned above?
Forgot what 7i93 does, so i'll go hide under a rock.

when we say updated we mean a serious update to be brought to compatibility with the latest changes in QtPyVCP, it would likely take a good bit. It is a bit too much to maintain both versions as they are completey distinct in their update requirements, really need a full time person to maintain it but no one seems to use it that wants to take on the responsibility unfortunately.

@Arciera,

From the document i found interesting line :
G1 X0 Y0 Z0 I-0.5 J0.5
K0.7071. For a properly defined vector

They use I,J,K for vector. But for G2, G3 that is not a valid gcode input. Preferr to use AB for the vector and use
C for the spindle orientation.

--
Basicly when using external rotary table, we could use this as axis u,v,w.
Where u=rotation around x, v=rotation around y, and w=rotary table clamp symetric axis.

Then we have a xyz, abc, uvw machine, 6 axis for tool, 3 axis for extern rotary table.

But this then is a single machine config that has valid kinematics for a few configurations like : xyz router,
xyz router + abc head. xyz router + abc head and a uvw rotary table.

So all other configurations, like xyzab, xyzac, xyza, etc need a different software approach.
And i think not all of these variants can use tooldirection optimalisation. Like xyza, where a is secondaire z axis.

So if i add selectors to the program config section :
1. xyzab
2. xyabc
3. xyz
4. xyza
5 xyzabc
6 xyzabcuvw

Then it should use correspondenting c++ function to translate gcode into the proper tcp, and other axis.
Like choosing kinematics.

What you think?







 

if you have a working configuration in axis, use the sim config ini file for probe_basic as a comparison for the bits and pieces required in probe basic.  I wish there was a better solution and maybe in the future we can sort out a more streamlined method, but it isn't too terribly difficult to get it going once you have a feel for linuxcnc'c configurations and how they work.  i need to make a new doc for the development version that recently released, but ive been completely covered with work.  in the interim just post up any questions here and we will see if we can get you fixed up.  and if you wouldn't mind noting anything along the way to perhaps help others that would be fantastic!

thanks,

Chris

  So hier einmal die gewünschte datei hoffentlich die richtige 

Ich habe keine qtvcpscreens

Habe aber paar verschiedene sim ausprobiert und nur bei plasmac tritt dieses problem auf.

Why would you not read the frequency directly,
as that would be faster and more accurate?

Linuxcncrio is another great project. The dev is a great guy.
I designed a couple of boards that connect to FPGA board available on AliExpress, so far I’ve been using Mesa firmware so it operates as a 7c81, but with some help from meister ( forum member & dev of linuxcnc-rio) I can also run his firmware as well.

I am at my wits end about this issue and am hoping someone can help me. I bought a sherline cnc lathe with the 4 axis driver box. I want to convert it to a more advanced cnc system with limit switches/etc so I bought a mesa 7i96s. Since the sherline driver box uses a parallel port, I looked up which pins on the parallel port on the driver box correspond to what (Such as pin 6 = z dir, 7 = z step, etc) I then used breadboard wires to individually connect the sherline parallel port pins to the associated pins in the mesa board and used pncconf.

However, I get two issues: first, the x axis does not move, but I am tabling this. The second issue is the focus: the Z axis ONLY moves backwards.

I connected sherlines Z dir to the dir+ and gnd to gnd of the stepgen pin row. I used a multimeter and verified the dir+ pin was working (it shifts to 5v when jog+ and stays at 0 when jog-). HOWEVER in halmeter or halshow I do not register any axistest.dir pin value changes, nor can i specifically find the 7i96s.stepgen.dir pin!! 

EDIT: I verified that halmeter and halshow do register the dir pin and it is working correctly, so i guess this means it is the mesa driver box or wiring that is the issue?

So I am completely confused on if this is an issue with the driver box/sherline or with the mesa/pnconcf/linuxcnc. My wiring to the axis looks correct.

PLEASE HELP

Everyone is welcome to join in, the more answers / ideas the better.

We're off to a good start.

One other thing I realize everyone uses their machine in a slightly different way so what's important to one might not be to another that being said if you think " he's obviously missing the ??? Button everyone needs that" let me know I'm at the blue sky phase so welcome to change.

Thanks again.

Actually, since we are calculating the tool orientation vector and later the rotary axis position for a given kinematic it seems we could just (or also) use generic 5axis gcode in vector format to start with. Not sure how widespread vector format output is in cam options though.

[edit]
www.fanucamerica.com/CMSMedia/DnP/Vector...e%20Machining_11.pdf

Where a rotates around x, b rotates around y. The c axis is the cone symetric axis, like spindle orientation.

Which reminds me that to calculate the tool orientation vector correctly we already need to know the kinematic for which the GCode was created. In your example the C axis value does not have any effect on the orientation tool path at all because it is applied last. If, however, the C axis was applied first (ie it would be the primary rotary axis) the path would look much different.

Hence we will need a way to encode the general type of kinematic in the ini file. We need to know whether the rotary axis is moving the tool or the work and if the rotations are on the same side (tool / work) the we need to know which is the primary and which is the secondary.

I assume there are economic software functions available to apply rotations to a given vector in any sequence?

nice!
I like the added preview of the tool orientation.