here  is complete setup for 250us position control loop ... with internal homing subroutine and internal probing input mapping for internal precision homing ability... you can select more methods of homing ... pos, pos + latch, neg, neg + latch ... but carefully map everything 

just enjoy !

Hello endian,
thank you very much for your reply.
The AX5201 is working fine now. I didn't read your desciption of your conversion tool carefully. So I exported the "Startup.xml" manually from TC3 and assigned it also manually in ethercat-conf.xml. With the parameters "complete -i" this is done automatically and works fine.
Thanks again!

Hi !
I tested today the new firmware and I have error at loading. Debug file information:Note: Using POSIX realtimehm2/hm2_7i96s.0: Unsupported or inconsistent PktUART TX module (version 3)not loading driver hm2/hm2_7i96s.0: failed to parse Module Descriptor 7hm2_eth: rtapi_app_main: Invalid argument (-22)./The(Mac)Mill(er).hal:9: waitpid failed /usr/bin/rtapi_app hm2_eth./The(Mac)Mill(er).hal:9: /usr/bin/rtapi_app exited without becoming ready./The(Mac)Mill(er).hal:9: insmod for hm2_eth failed, returned -12659Stopping realtime threadsUnloading hal componentsNote: Using POSIX realtime/////////////////////////////////////I noticed that the other 7i96S firmwares use PktUART2. I tried modifying the vhd with the Efinix tools, but it seems I would need the full project sources to properly change the PktUART version and rebuild the firmware. Would it be possible to provide a version of this firmware compiled with PktUART2? It would help a lot.Thanks in advance!

I may have not explained what I am after very well. With the variator, if we are properly tuned at 1:1, we would get a problem, as with, for example, 2:1 the same tune would overshoot massively, and with 1:2 we would undershoot.

So what I want is to measure the motor RPM and spindle RPM to get the transmission ratio and scale the PID error accordingly to have a similar response to the point at which it was tuned. I am not after controlling the motor RPM directly.

But to know if this will work or not, I have to get the tune at one point right first, see problem 1 of my previous post.

Sounds like an asynchronous motor with a couple of percent of slip. I dont think we need to control RPM to any really close tolerance. The only time we do commanded speed change with the tool in engagement is a CSS facing cut, or a taper cut, both of which change speed pretty slowly.

I think it will be a real challenge getting this level of control packaged into the HAL. I started working on a comp for it.

The system accepts 128 digital inputs and 128 digital outputs by simply adding the expansion card on the desired side and updating the loadrt command in the .hal file with the number of expansion inputs/outputs installed. Expansion cards work on either side.

Hi all,

I'm having an issue with LinuxCNC not completing the entire command as written in the G code file.

Here's a piece of the code:
G0 Z1.0000 
(PASS 1)
G1 X-2.3750 Y2.7250 F8
G1 Z-0.0500 F4
G1 X-2.3750 Y1.3915 F8.0000 
G3 X-2.3738 Y1.3811 I0.0211 J-0.0029 F8.0000 
G3 X-2.3585 Y1.3750 I0.0112 J0.0058 F8.0000 
G1 X1.7250 Y1.3750 F8.0000
G1 X-2.3750 Y2.7250 F20
(PASS 2)
G1 X-2.3750 Y2.7250 F8
G1 Z-0.1000 F4
G1 X-2.3750 Y1.3915 F8.0000 
G3 X-2.3738 Y1.3811 I0.0211 J-0.0029 F8.0000 
G3 X-2.3585 Y1.3750 I0.0112 J0.0058 F8.0000 
G1 X1.7250 Y1.3750 F8.0000
G1 X-2.3750 Y2.7250 F20

If I single step the code, the command is completed as written. If I let it run, it completes MOST of the command and then it starts on the next command.

See pic.

 

Our borax doesn't go away due to evaporation, but we do lose some to drag-out when we're too impatient to drain parts and scrap in to the table.

Problem with borax is that it doesn't mix well; we've found heating up a couple gallons in the house and dissolving it works.  The concentrate can then be poured in the table and it mixes up ok during the drain/fill cycle.

I worked again at the spindle.

I have a “theory” on how to handle the two gearings of the machine.

First, I try to get the motor RPM into LCNC. With the analog out from the VFD, I am now able to get this with an accuracy of about ±25 RPM, which is less than 5% off. I measured the real RPM with a cheap optical tachometer and the RPM that the VFD “thinks” it is at. These two were consistently very close. The VFD was consistently 3 to 5 RPM higher than the tachometer, in an RPM range from 880 RPM (at 30 Hz) to 2080 (at 70 Hz). 3 to 5 RPM seems close enough to ignore that error and believe the VFD.

Now, having the motor RPM, I set the variator by hand so the overall reduction ratio was 1:1 (or close to it)

My plan is to tune the PID at this point and later multiply the error term (pid.s.error) by the overall reduction ratio. If I am not thinking about this totally wrong, this should give the system a hopefully somewhat stable spindle PID over the very large reduction that the backgear and variator provide.

Now I do have 3 problems:

1: There is something wrong with my pid.s setup. As soon as the error gets significantly negative, the output shoots up and the system runs away. I found that pid.s.output can be between 3000 and -3000, but I use 0–10 V, not ±10 V, so as soon as pid.s.output goes negative enough, it runs awaythe sign seems to be ignored. I think this has to be a somewhat common problem with 0–10 V. I was able to remove the runaway by using a limit component to cut away the negative part of pid.s.output, but that led to strange behavior as well. With this, I can increase P to large values without it starting to oscillate much.

2: I was able to get the motor RPM, and I have the spindle RPM, but putting both into a div2 component gives 0 at all times. And not a close-to-zero float (e.g. 5.459834658e-7), but actually just 0. I thought it had to do with the deadband, but no value of that seemed to resolve this. The spindle RPM is obviously 0 when the spindle is still, so I do have a limit component to keep the spindle RPM at ≥ 1, resolving divide-by-zero issues. And as soon as the spindle spins, the numbers seem fine.

3: I already foresee a future problem: given that I have the gear ratio and a solid PID at a ratio of 1:1, I would need to scale pid.s.error (reduction_ratio * pid.s.error), but I could not find where this variable is set, so I would not know how to set my scaling factor.

Sorry for this long rambling message, I hope I was able to explain what is going on on my side.

Thanks

Just to tidy up this thread, here is a pic of my working PB Lathe setup...

 

But the main question is still open: is there any way to tell the backplotter where the centre of rotation is, when the rotary chuck is not at machine Y=0?

In my case the chuck is fixed at Y=700mm. The backplotter always rotates around Y=0 (machine origin), so the wrapped toolpath displays as a large circle far from the actual machine envelope instead of showing correctly near the chuck.

I have already seen the 2013 thread where andypugh said there is no solution.
Is this still the case in 2.9.8, or has anything changed since then?