Advanced Search

the faster the pulse count, and the smaller the unit of measure, at a fixed frequency, the bigger the problem becomes. I am referring to a edge case but it is something to beware of. 

Oh, it is a little baby machine by many measures- 1 kW spindle, 12x6x10" XYZ travel or so, etc. Weighs, I dunno, maybe 500 lbs? I built it with a welded steel frame filled with epoxy granite, with proper linear bearings and ballscrews (to be fair, I got nice THK linear bearings, cheaped out on the ballscrews), so hobby bench mill sized, but with way more rigidity. The BT30 spindle is probably overkill, but it was available, and there's a lot of tooling options. TTS didn't seem like a great option, and ISO20 seemed too small.

Aside from this issue popping up, it's been a great experience coming from the gantry-style machine I'd been tweaking for years. The rigidity, Z height, and toolholders are the huge upgrades, but the MPG, touch probe, covered ways, coolant control, spindle/axis stall-detection, and servos are very nice as well. Having a spindle with enough torque at reasonable RPMs to actually handle (small) drills is still blowing my mind.

Sorry for the crappy picture- literally just walked over to snap it, so you can see it's a bit disassembled for debugging (and with random scrap taped over the t-slots so I didn't have to clean them out). That's a Kurt 4" DX4 vise for scale.

May need someone familiar with spindle orientation
to debug this but the orient P and FF1 terms do seem
very high.

What happens when orient is attempted?

dumping all orient related pins/signals may help

So when you do an orient operation, run this command:

halcmd show all  | grep orient

 (in a terminal)

or

halcmd show all  | grep orient > orient.txt

and post orient.txt here



 

im trying to do orientation but cant get nothing to work. the encoder is working but still it isnt closed loop and no orientation what so ever. hopefully you can see something wrong in my files haha.

You need to also set the FANUC interface timer to  timer you  have setup
(like timer 1) I don't know the name of the pin off hand but listing
all the fanuc pins should find it. Do you have a oscilloscope available?

With the AA64 setup you should get a 8 usec request pulse (+ to REQ+ and - to REQ-)
at the servo thread rate, The encoder should respond with 77 bits of data on the +/-
DATA lines

Note that the default AA64 setup is for a 64K count/turn encoder so wont be right
but should show some data. The correct setup for your 1m count/turn encoder
would need the appropriate setup string

 

Thanks, I have experimented with the polarity of the data and request lines with no changes. Here's where I left off in the .hal based on what I could find here on the forum. I think I have added the initialization of DPLL but not sure about setting the timer.

Thanks!

Hi there!
I'm also running an IMA quadroform c80/280! We are still using the NUM1060 controller, but we are still adding new features. We have already created an open source Estlcam 12 post processor to create IMAWOP FMC files.
git.makerspace-darmstadt.de/ima-baz/ima-bima-cad-converter
We have integrated our machine into the network to read the src files via NetBeui, we have understood and edited some of the internal macros and we have documented many steps from beginner tutorials to advanced calibration of the machine.
If you're interested in further exchanges, just write me an e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. .
I am very interested in meeting other owners of the same machine to discuss some specific problems and share some documentation!
Regards
Paul

Ahoj pane
Had this issue once a few years back, try another slot.
If that does not work, remove the card, start the PC, enter the BIOS, find something like "resources" or " IRQ" or ... i forgot, but basically the part that sets the IRQ for everything is usually set to auto, so set to manually, save, power off, insert the card, it should boot OK but in some cases might have sluggish response on the desktop, and if that happens, reboot, enter BIOS, go again there and assign manually an IRQ for the Mesa, whatever just not the same one with the graphic card.

Sometimes updating the PC BIOS can help the issue.
Card testing is done on a H97 or D525 motherboard and I
don't think we have any motherboards that don't work
but I can get a HP 8200 SFF to see if there is a workaround

 

2. from what ? Aliens?
3. damn, that is a big machine, i thought it was some small hobby thing.
Does it use ballscrews?
If yes, try machining the same part with the same gcode but in another place on the table. Might be a broken ball.
Or might be a broken ball in linear rails, so decoupling the motor and spinning the screw by hand slowly might find a bump.

Hello everyone!
I have a problem with installing the Mesa 5i25T card. I have an HP Compaq dc7900 computer. I installed Linux CNC from the official website on my computer, it was without any problems, it works. However, after inserting the card into the PCI slot, the computer will not start, it remains stuck in the bios. After removing the card, the computer works again without any problems. I also tried an HP Compaq 8200, but the same problem. I also tried putting the card in my large computer for drawing, I used a hard drive with the system from previous computers, and the card works. However, when performing Mesaflash, it writes an error: Unauthorized memory access (SIGSEGV). I assume that this is caused by the fact that I installed the system on the hard drive on another computer. The jumpers on the card are set to default. Do you have a tested PC setup on which this card works? Thanks for the advice and greetings from the Czech Republic!

1. Entirely plausible

2. Yes. The point of those was to highlight the noise seen is very high frequency, and seemingly unlikely to cause steps

3. Spindle is a BT30 taper with a manual drawbar- no ATC/belleville washers/pull studs/etc. End mill is held in a Nikken SK10 collet holder torqued to 35~40 ft-lbs, which is the recommended value. Tools are changed with an impact driver on the drawbar.

4. I should definitely re-run the code and see if I can reproduce. Haven't wanted to spend the time/material doing so, but I've wasted enough other time on this to dwarf both costs. I'll rerun both with the same tools originally used and also with a different one. May or may not have time to do that today.

5. I put an indicator on the tool and pushed on it. I can get it to deflect ~0.0005 (5 tenths) before I don't really want to push on it any harder. Seems to apply going any direction.

6. So climb vs conventional? I've thought about this, but the pocket was roughed with an adaptive/HSM toolpath, which started in the center of the pocket- so the cutter is roughing -Y to +Y on the +X side of the pocket, and +Y to -Y on the -X side. Correct me if my logic is wrong here, but if cut direction were the problem, wouldn't you expect to see issues in (eg) the +X+Y and -X-Y quadrants instead of the -Y half?


Grounding: One ground loop snuck in (shielded cable with shield connected at both ends), though disconnecting that has no impact on noise I can see. Will fix it anyway.

Beyond that, I wouldn't rule ground issues out, but am not seeing an obvious issue. The entire cabinet is aluminum and grounded. It's not a single point due to eg the filters, PSUs, and spindle drive all grounding through their chassis. The axis motors have a completely isolated supply (transformer-based)- as far as they're concerned, the world is the isolated 65V and a couple opto-couplers. The 24V and 5V negatives are all tied to a single bus bar- which is NOT ground. A multimeter shows an open circuit between 24V negative and the enclosure. The machine body has no dedicated ground, but is grounded indirectly via the spindle motor. The axis motor bodies are electrically connected to the machine, but that's isolated from their power supply.

Spindle drive has all the recommended filtering. I deviated slightly from the recommendations by omitting fuses on the logic power, replacing the contactor with an SSR, and placing said SSR before all the filtering, though I don't see an issue with that. Pictures show datasheet drawing and the schematic of how my machine is wired.

Noise is much better when motors are disabled- got it on my to-do list to see what's the root causes there. Guess is the spindle drive, but need to verify. No ferrites on anything at the moment- and no mention of them in the DYN4 (spindle) nor ClearPath (axis) manuals. Not to say they wouldn't help, just that the manuals don't call them out as important. The PSUs are MeanWell units, so at least not no-name. SOP is to not buy dubious PSUs- they can cause too many problems and take out too much valuable hardware to be worth the risk. Not to mention noise, as you say.

The ping latency seems to be good, mine (with mesa) gives 0.2ms. If your latency won't get higher after a longer time of testing it should be good enough.
You could try to increase the servo_period to 2000000

With an Optiplex 3040m I had good results with these parameters:
isolcpus=3 intel_pstate=disable processor.max_cstate=0 idle=poll cpufreq.default_governor=performance i915.enable_dc=0 ahci.mobile_lpm_policy=1 irqaffinity=0 nomodeset quiet

From 1x8gb to 2x2gb (of the same brand/speed) for dual channel also improved the latency
forum.linuxcnc.org/18-computer/39371-res...cnc?start=330#271127

In your case it should be isolcpus=1

If the error still appears it might be helpfull to upload your ini file.

This setting gives an error, when going G0 G53 Z0, because max limit reached
Its better to have MAX_LIMIT = 0.1

Thank you @Aciera.

It does work as expected now.

Have a nice one.

Cheers,
Mateusz