Advanced Search

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.

Hello,

At 60000mm/m the velocity is 1m/s or 39.37 IPS. In the world of linear motion this is quite fast. In the world of CNC, that is astronomical speed. Typically reserved for G00 commands for initial positioning. The limiter here would be the cutting feed. No tool can cut effectively at that speed of 60000mm/m. The scale of limitation is determined by the material being cut as a measure of chip load. Even the softest materials such as MDF have a finite chip load that will limit the overall max velocity of the command. Typically near 8800mm/m or 8.8m/m. Pretty simple.

If I have a 10mm pitch ball screw which will provide 10mm of linear travel per rotation I would need to rotate the ball screw 880 times to move exactly 8.8m over 1 minute. Again, pretty simple. That also means my motor will rotate at exactly 880 RPM. Or 14.6 RPS. If I need to move 1mm at that velocity of 146mm/s I would arrive at my desired position in .146 seconds or 146ms. If I use the same velocity for .5mm then my time of arrival is cut in half. and so forth. Since we are on a 1ms tick cycle and assume 50% of the time on the bus for sending the data to the slave and the slave responds in real time we can assume that the slave can effectively make the 1mm move 6 times +- per second. Not that anyone would ever do this, but for example sake... If I use a 20mm pitch ball screw I can double my speed to desired position of 1mm@8.8m/m at a reduced force arriving in .073ms(assumes a command multiplier in the slave). Now having the ability to move this distance more than 10 times per second. I can further modify this by increasing the command multiplier through EGR or additional pitch on the ball screw to say 50mm. The above only allow for less transmitting of positional data without having to lower the bus speed because the controller need only send half or less the moves to achieve that same ends. *Note - The above assumes you have a 23bit ABS system to allow for maximum PID control at such speeds. Since LCNC is Position Mode only you need the drive to have as much feedback data as possible so that the PID sampling is very tight keeping actual error low.

As you can see, if one is trying to use EtherCat via CoE at 1ms tick cycles, the machine performance with LCNC is more than ample to meet the specifications required to match the maximum effective cutting performance.

The positioning error is also easily managed by a drive that has a 1Khz sampling cycle at the speeds above. Although most drives of substance have a 10Khz sample rate such as Omron, Yaskawa, LS Electric. This is a function of the drive and not of LCNC since it is in Open Loop from LCNC to the drive. The drive closes the loop and uses its' internal algorithms to control the PID.

The accuracy of each move is determined by the drive/mechanical as a function of inertial load and the ability for the drive to control the jerk loads and closely manage settling time. Settling time being a function of the ability for the drive to acknowledge position arrival once settling is complete and is ready to accept the next command given.

At the end of the day, the performance of LCNC is well within tolerance for machine tool applications as long as the hardware choices by the end user are sufficient to drive the given load at desired velocities within a desired overall accuracy.

For nm following error, one would have to have a RT kernel written specifically to only handle the Ecat bus and have a dedicated driver for the PHY(Ethernet Port) to only allow for ECAT bus frames with no interrupts and absolutely zero addressing. This system would be a subsystem of the main kernel. More or less a PC in a PC. Kingstar uses Interval Zero RTX64 in a windows environment. The RTX64 RT is a sub OS that runs along side Windows. Kingstar layered in the ECAT framework inside the RTX64 OS and has achieved a true PC based ECAT with 100 um tick cycles with DC. It works flawlessly. But, it only works in Windows. Mach4 worked with them with me as an advisor to form the integration about 8 years ago. It still works today.

Mach4 has an issue though. They use wxLua for the GUI control and it crashes a lot making it unreliable. Hence, I never pushed forward due to the fact that Mach4 staff would not move away from the terrible wxLua system. The TP designed by the lead programmer is bar none one of the best but I require 99% uptime for my controllers. Mach4 barley breaks 90%. One side note is that I was able to during the same time have Mach4 built with custom Macro B and exactly mimic Fanuc macro variables for a linear compat for my clients who wanted to shift to Mach4 for cost but not sacrifice the overhead of rewriting hundreds/thousands of fixed programs that utilized Macro B. Still works today. But like I said, the wxLua aspect was a deal breaker.

If application desire is to have nm error at speed, you need to use Torque mode over ECAT and use a controller that accommodates that functionality to which, as far as I can see LCNC/Etherlabs has not implemented fully. You would be on your own to write the kernel config and PHY driver for that. Possibly even move it away from the uspace domain. Hard to say. If I were to do what you attempting, I would use a different CNC software specifically deigned for that purpose. But, I do fully understand the cost factor. Unless maybe you can get Biden to subsidize your desires... Lol.

I would find it more than interesting to see if you can achieve your goals in LCNC. Is it possible? Sure. Anything is possible.

hm2_eth: ERROR: Could not retrieve hardware address (MAC) of 10.10.10.1: Connection refused

Wrong IP address for the Mesa card (unless you changed it)

@Hi,

I just made a test for 5 axis. xyz abc.
Where a rotates around x, b rotates around y. The c axis is the cone symetric axis, like spindle orientation.

The tool direction line is 15mm of lenght.