Advanced Search

djdock99 wrote:

.... i can manually latch relay 19k1 by holding on the contactor with a screw driver.

Never smart to do that to machines.

djdock99 wrote:

.... but the x and z servos are rotating slowly but smoothly.

This means that LinuxCNC has no control over the servo drives, usually incorrect or missing wiring, like are the encoders wired to Mesa and do they work correctly counting up/down on the LinuxCNC DRO ?

djdock99 wrote:

Then when i update the hal file to electronically latch 19k1 with f2 it will not hold and drops relays straight away.

What error does LinuxCNC show when that happens?
I would bet it shows "joint.n.following-error" as noted on my second reply.
-
You are working on a complicated machine, so it is imperative to follow instructions strictly and as listed in priority.
See this for wiring and testing:
forum.linuxcnc.org/10-advanced-configura...to-example-mesa-7i77
And for network and WiFi to work at the same time, see here
forum.linuxcnc.org/27-driver-boards/3559...ethernet-mesa-boards

On the HW side the break (VFD + and 0) nodes would also need to be duplicated or relayed over.

In a terminal, what does
ip a
return?

That typically means a connection issue

Either the link was not up when LinuxCNC started, the IP address was wrong or similar

 

Well, after racking my brain for several days, I've managed to understand and solve the problems. The problem with the reverse gear is that the servo's DI4 signal is 24V, so when connected to pin 16 of the bobbin, it always has voltage, and the signal remains active even when you activate or deactivate reverse. The solution was to use a 5V to 24V optocoupler.

Regarding the RPM problem, I've managed to understand how the spindle scale works, allowing me to calibrate the RPM perfectly.

There are many factors involved, such as the bobbin not delivering an exact 0-10V signal, and you have to play around with the offset in LinuxCNC and the driver itself.

It's a real headache, but when you finally understand it and manage to solve it, it's very satisfying.

Thanks - of course -so simple i should have noticed it myself
Next error after changing name of hal in ini:

Debug file information:
Note: Using POSIX realtime
hm2_eth: rtapi_app_main: Resource temporarily unavailable (-11)
./main.hal:9: waitpid failed /usr/bin/rtapi_app hm2_eth
./main.hal:9: /usr/bin/rtapi_app exited without becoming ready
./main.hal:9: insmod for hm2_eth failed, returned -1
2077
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime

Why "temporarily" unavailable?
 

Hi 

Wondering if anyone has tried to setup PathPilot (PP) to use 2 VFDs, one for the main mill spindle and the other for the RapidTurn (RT) spindle.  They are different size motors so require different VFD parameter programing which is normally done via a shut down and then VFD key swap.  I am wanting to avoid the shutdown to save time and preserve the part and machine coordinates.

Situation, my daughter and I are working on a project that needs lathe operations and milling operations and with the rapid turn having the indexing every 15 degrees that makes for a perfect part holding solution after the lathe ops, but only so if we did not have to shut down to switch PathPilot and VFD parameter profiles.  Note:  We are not needing both modes to work at the same time, that would be a PP nightmare and is suspect the MESA card could not pull that off either.  But if it's one or the other that lowers the bar greatly!  Here is what I am thinking:

• HW/Electrical Solution:  PCNC 1100:  Add a second VFD, 1 dedicated to the Mill motor, the new one dedicated to the RapidTurn motor, so wiring would be quite simple, as we only need to swap the control wires. 
  • The 3-phases to the motors are dedicated to each motor so hard wired from respective VFD. 
  • The power to the VFDs could be from the same source to each VFD. 
    • They would not run the motors simultaneously. 
  • The few control wires would need to be relayed between the two modes. 
    • With the default relay position pointing to the mill's VFD so that part always works.
    • Note:  They would be in a static / OFF (floating) state when being switched over. 
    • Would likely still do a small ckt to ensure clean switch over if this solution works.  I have a used VFD on its way here already. 
    • There is a VFD reset IO that could potentially be used via USB relay to force it to load an alternate parameter file, but for now am going to ignore that potential option as the relays is super easy and quick
• SW solution:  Have not dove into this yet and SW is no longer a strong front, so advice/support is greatly appreciated on all fronts. 
  • The idea is to have the PP settings screen RapidTurn Button that switches the mode (Mill vs Lathe) continue to do so, maybe even add an option to also trigger the swap via an M-Code indicating mill or RT. 
  • Key need is:  That PP continue to operate without issuing a reboot, thus preserving its coordinates
    • TBD what that means between a lathe and a mill, but the idea is to not have to remeasure part origin parameters which can be derived from the previous machine type mode's part origin, likely use the 4th axis coordinates to facilitate this.
  • That would require some relationship be pre-established between the mill and the RT.
  • I have to dig into why needs the reboot, hoping it's only for the VFD and wousl simply mean commenting out the reboot and forcing the code to a post reset state in the new machine mode. 
    • Technically on a PCNC 770 w/RT there is no need to change over the VFD parameters as, If I am not mistaken, the rapid turn and the 770 spindles use the same type/size of motor, only the phase wires between motors would need to be relayed over, thus that machine would be cheaper easier to do this to

Any thoughts, Thanks,
E1

Is there any communication happening?

That is, do you get a fault if the VFD is not connected?
 

You have basic7i97.hal in your .ini file but I think 
you wanted main. hal there instead.

That's why you get this error:

CANNOT FIND FILE FOR:basic7i97.hal

inputs and outputs

Help me please????I have spent 3 days trying to get linuxcnc to power on the Maho with no success.Where i am at. With linuxcnc open and the machine released from estop i can manually latch relay 19k1 by holding on the contactor with a screw driver. When i do this the whole machine powers up and everything is working perfectly. the drives are enabled the linear scales are reading correctly. the door open closed switches are all working correctly but the x and z servos are rotating slowly but smoothly. Then when i update the hal file to electronically latch 19k1 with f2 it will not hold and drops relays straight away.

Is there an easy way to get the feed rate to show up on the screen somewhere? (old 2.7x version)
For various reasons (I use some css and when it's working well I'd like to know what combination of rpm and feed it's actually using) I'd like to see the actual feed the z-axis is on my lathe as it cuts whatever given diameter. I've got a add-on panel showing the actual spindle RPM so although not as straight forward there should be a way of showing the actual FEED of whatever axis. Since somewhere in there should be the pulse rate of the stepper I think it might be available or would I need to have an encoder on that motor/ballscrew and calculate out the feed that way ???
Mooser
 

  I think my voltage spikes seemed to disappear when I connected the board.So now im ready for the next step in my "simple retrofit machine"

• only one motor standing on the table waiting for action
  • enable directly to the Rexroth DKC11.3 drive

able to jog x motor in Axis.Unfortunately it didnt workWhen starting the configuration in Linuxcnc i get the message:
Note: Using POSIX realtime2573Stopping realtime threadsUnloading hal componentsNote: Using POSIX realtimeI have tried several things but now it seems that im stuck with this message.Any ideas?I attach report, hal and ini        

File Attachment:

File Name: homagretrofit.ini
File Size:3 KB

File Attachment:

File Name: main.hal
File Size:3 KB

File Attachment:

File Name: io.hal
File Size:0 KB

File Attachment:

File Name: linuxcncreport.txt
File Size:5 KB

Ok, I continue with the 10 I have guessed and set.

Seeing that you understand pretty well what is going on, what will you do different with a new driver?

That makes sense... today i did a new clean install using Debian 12 Bookworm and Linuxcnc 2.9.0~pre1+git20230208.f1270d6ed7

Still get some errors -> attached picture

kcjengr.github.io/probe_basic/machine_config.html