Advanced Search

thanks tommy for the reply. regarding pushing the contactors, i hade to prove that the machines electronics are working properly and that the push button 3sh1 which powers 6a1 safety relays temporarily until 19k1 is latched was working correctly. all the safety systems of the machine are not be touched. similar to Rotarysmp's mh400 retrofit.

Linear scales are reading correctly on the dro and as you can see from the ini file posted above i have accurately populated the scales values.

regarding the indramat drive signals i bet your right and i know i have something wrong here but im having trouble figuring out what. +10 and -10 wires are connected to the 7i97ts and i have left the original drive enable circuit untouched as this is handle by a contactor called 7k1 whose coil is pulled when 19k1 relay has been latched leaving mahos estop and error indictor logic untouched. can this work?

linuxcnc does not show joint.n.following-error but it did before i added an extra ground from +10-10 cable sheathing cables sheathing.

contactors fire and back to estop errors. i know im doing something wrong but writing this and try to explain whats going on might help. thanks for your help

Hey Guys,
bad luck. The communication seems to run between mesa and Vfd. 
Now i measured (in parallel) the connected Mesaoutput with Vfd Input. (mesa_modbus.png)
Compare to the connected USB-Dongle output and Vdf Input (USB_Modbus.png)
Signal Quality looks pretty good. (pktuart seems to work)

I figured out by using the USB-Dongle, that i have to set some Frequency to get this RUN-LED flashing on my OmronMX2 Vdf.
So I implemented all the other necessary Hal Pins to .hal file to check this with the Mesa <--> Vdf communication.
Know, if i click the CW AXIS GUI Button, Iḿ getting the same Error at my Vdf ( E12.1 like a few days ago).

From my point of view, there must be something wrong with the run, reverse or cmd-freq command.
Or still some wrong configuration somewhere.
Iḿ still getting no Vdf temperature out of the Vdf.

so write or read is not Working, 
my current .mbccs:
Can someone explain these?

Once, i had one PDU Error. But i guess it was only a wrong configuration.
Iḿ loosing my motivation, i wasted 3 weeks now 3h a day

 

Hopefully have a completely stable firmware and some type of watchdog to keep track of the communication. By the way, with firmware I speak about the USB dongle and with driver I mean the computer/LinuxCNC component.

I'm not completely happy with how the LinuxCNC xhc-whb04b-6 component works either. And at least for me, the amount of abstraction layers in that code makes it difficult to understand/change.

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