Advanced Search

Search Results (Searched for: )

  • ziggi
  • ziggi's Avatar
30 Jun 2025 21:49 - 30 Jun 2025 21:53

Troubles to get started with SD240 Retrofit

Category: Turning

Thank you PCW- appreciated! I will add this asap and test it.
Thanks a lot
Ziggi
  • PCW
  • PCW's Avatar
30 Jun 2025 21:10

homing with Phase Z encoder on MESA 7i96s

Category: Advanced Configuration

Did you check the home switch operation?

That is, does  joint.2.home-sw-in go true (change from red to yellow in halshow)
when you manually trip the home switch?
 
  • Ac1dburn
  • Ac1dburn
30 Jun 2025 20:35

Remora - Rpi Software Stepping Using External Microcontroller via SPI

Category: Computers and Hardware

Thank you for the reply scotta,
I'm assuming you meant to say LPC1769
As I'm not using an LPC1768 on the turbo. I'll take a look at what you sent and report back
  • scotta
  • scotta's Avatar
30 Jun 2025 20:28

Remora - Rpi Software Stepping Using External Microcontroller via SPI

Category: Computers and Hardware

The LPC1768 is legacy and I suspect that you have installed the current version of the remora component for LinuxCNC. The data packet was updated since the LPC1768 development stopped.

Try this component
github.com/scottalford75/Remora/tree/mai...NC/Components/Remora

You're very close by the looks.
  • Bertho
  • Bertho
30 Jun 2025 20:26

How to write multipule data ( byte) mesambccc

Category: General LinuxCNC Questions

A fix for the indicated problem has been committed to the master branch. It also includes several other fixes to provide better support for this and other devices by introducing byte types and some extra attributes.

The following mbccs file I suggest to use as a starting point. It only works with the new patches because it uses the new byte-types. Also, many types have been corrected to use the proper signed types and sizes. The interval is set to let the commands loot at 10Hz. There is probably no point in hammering the device with queries continuously.
Extra configuration may be necessary because some pins need to have a very specific values when you write (according to the docs; these are record written in a transaction). It will require starting the driver in suspended mode and use a hal-file to do pin setups before taking the driver out of suspend.

There are many issues that need to be addressed in this configuration. See also the comments in the below code. I do not know what exactly you are trying to do, but some reads are static data and some writes are probably one-time setup values that never will change during operation (and should therefore be initlist entries). Static data is not normally what you continuously want to read or write in a loop.

It is probably a good thing to try to define exactly what you are trying to achieve and control in the modbus communication. What running data is extracted/used elsewhere and what running parameters are to be live tuned. Remember, read function will read continuously and write functions will write every single change to a pin.
<?xml version="1.0" encoding="UTF-8"?>
<mesamodbus baudrate="115200" parity="E" stopbits="1" interval="100000">
  <!-- Note the interval setting: 100000 us (10 Hz) -->
  <!-- It may be necessary to start suspended (suspend="true") to setup pins before starting to send data -->
  <devices>
    <device address="0x02" name="mrje70a">
      <description>Manual for MR-JE-_A device communication:
  title: "MR-JE-_A SERVO AMPLIFIER INSTRUCTION MANUAL (Modbus RTU Protocol)"
  link:  https://dl.mitsubishielectric.com/dl/fa/document/manual/servo/sh030177/sh030177c.pdf
See chapter 6 for modbus types.
      </description>
    </device>
  </devices>

  <initlist>
    <!-- There should probably be some commands here... see comments below -->
  </initlist>

  <commands>
    <command device="mrje70a" function="R_REGISTERS" address="0x2b01" unaligned="1">
      <pin name="cfp" modbustype="S_CDAB" haltype="HAL_S32" />
    </command>
    <command device="mrje70a" function="R_REGISTERS" address="0x2b0f">
      <pin name="volt" modbustype="U_AB" haltype="HAL_U32" />
    </command>
    <command device="mrje70a" function="R_REGISTERS" address="0x2b2d">
      <pin name="power" modbustype="S_AB" haltype="HAL_S32" />
    </command>
    <command device="mrje70a" function="R_REGISTERS" address="0x2001" unaligned="1">
      <pin name="rpa01" modbustype="S_CDAB" haltype="HAL_S32" />
    </command>
    <!-- Not sure this should be read all the time -->
    <command device="mrje70a" function="R_REGISTERS" address="0x2801" modbustype="U_AB" haltype="HAL_U32">
      <pin name="rnument-2801" modbustype="U_A"/>
      <pin name="position" modbustype="S_CDAB" haltype="HAL_S32"/>
      <pin name="speed"/>
      <pin name="accel"/>
      <pin name="decel"/>
      <pin name="dwell"/>
      <pin name="subfunc" modbustype="U_A"/>
      <pin name="mcode" modbustype="U_A"/>
    </command>

    <!-- NOTE: The following command is only read *once* because EEPROM data is static data -->
    <command device="mrje70a" modbustype="U_CDAB" haltype="HAL_U32" function="R_REGISTERS" address="0x1010" interval="once" unaligned="1">
      <pin name="rnument-1010" modbustype="U_A"/>
      <pin name="eesave-all-parms"/>
      <pin name="eesave-comm-parms"/>
      <pin name="eesave-app-parms"/>
      <pin name="eesave-factory-parms"/>
      <pin name="eesave-point-table"/>
    </command>

    <command device="mrje70a" modbustype="U_CDAB" haltype="HAL_U32" function="R_REGISTERS" address="0x2c12" unaligned="1">
      <pin name="rnument-2c12" modbustype="U_A"/>
      <pin name="rextindsp-1"/>
      <pin name="rextindsp-2"/>
      <pin name="rextindsp-3"/>
      <pin name="rextindsp-4"/>
    </command>
    <command device="mrje70a" modbustype="U_AB" haltype="HAL_U32" function="R_REGISTERS" address="0x6041">
      <pin name="status"/>
    </command>
    <command device="mrje70a" modbustype="U_AB" haltype="HAL_U32" function="R_REGISTERS" address="0x6040">
      <pin name="rcontrolword"/>
    </command>
    <command device="mrje70a" modbustype="S_A" haltype="HAL_S32" function="R_REGISTERS" address="0x6061">
      <pin name="mode"/>
    </command>

    <!-- This is probably not something you want to read all the time. -->
    <!-- Does this change? it is written down below, see comment there. -->
    <command device="mrje70a" modbustype="S_AB" haltype="HAL_S32" function="R_REGISTERS" address="0x2d60">
      <pin name="rtargetpt"/>
    </command>

    <command device="mrje70a" modbustype="U_CDAB" haltype="HAL_U32" function="R_REGISTERS" address="0x6099">
      <pin name="rnument-6099" modbustype="U_A"/>
      <pin name="rhps-spd-switch"/>
      <pin name="rhps-spd-zero"/>
    </command>

    <!-- *** Write commands follow *** -->
 
    <!-- Setting the control word will need to be setup properly on the pin *before* the driver starts sending data. -->
    <!-- It also might be an initlist entry -->
    <command device="mrje70a" function="W_REGISTERS" modbustype="U_AB" haltype="HAL_U32" address="0x6040">
      <pin name="ctrlwordwt"/>
    </command>

    <!-- Setting the operational mode should most likely be done in the initlist -->
    <command device="mrje70a" function="W_REGISTERS" modbustype="S_A" haltype="HAL_S32" address="0x6060">
      <pin name="wopermode"/>
    </command>

    <!-- Setting the point table reference will need to be setup properly on the pin *before* the driver starts sending data. -->
    <!-- If it is to be in the command list, then writeflush polarity must be considered -->
    <!-- It might be required to be an initlist entry, as this is most likely a static config -->
    <command device="mrje70a" function="W_REGISTERS" modbustype="S_AB" haltype="HAL_S32" address="0x2d60">
      <pin name="wtargetpt"/>
    </command>
 
    <!-- Setting homing speed should probably be done in the initlist -->
    <!-- *** This write requires pin setup /before/ it is sent. *** The wnument-6099 should to be set to 0x02. -->
    <command device="mrje70a" function="W_REGISTERS" address="0x6099" modbustype="U_CDAB" haltype="HAL_U32">
      <pin name="wnument-6099" modbustype="U_A"/>
      <pin name="whps-spd-switch"/>
      <pin name="whps-spd-zero"/>
    </command>
  </commands>
</mesamodbus>
  • JackRay
  • JackRay
30 Jun 2025 20:08
Replied by JackRay on topic homing with Phase Z encoder on MESA 7i96s

homing with Phase Z encoder on MESA 7i96s

Category: Advanced Configuration

Are you saying that my .ini file is misconfigured and that's why I can't detect my Z homing?
  • Tntmold
  • Tntmold
30 Jun 2025 19:46
Replied by Tntmold on topic General Questions about using ethercat

General Questions about using ethercat

Category: EtherCAT

I have linuxcnc loading but the steppers still won't move.  Ethercat Slaves shows drive is in OP mode, but when I use "ethercat upload" to check drive parameters, I see that the drive is not in CSP mode.  Where is this supposed to happen?
  • PCW
  • PCW's Avatar
30 Jun 2025 18:41 - 30 Jun 2025 18:42

Troubles to get started with SD240 Retrofit

Category: Turning

You are missing the "servo-thread" for the "jogincr" component

that is:

addf hm2_7i80.0.read servo-thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf pid.x.do-pid-calcs servo-thread
addf pid.z.do-pid-calcs servo-thread
addf pid.s.do-pid-calcs servo-thread
addf jogincr
addf hm2_7i80.0.write servo-thread

should be:

addf hm2_7i80.0.read servo-thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf pid.x.do-pid-calcs servo-thread
addf pid.z.do-pid-calcs servo-thread
addf pid.s.do-pid-calcs servo-thread
addf jogincr servo-thread
addf hm2_7i80.0.write servo-thread
  • PCW
  • PCW's Avatar
30 Jun 2025 18:35
Replied by PCW on topic Lo ejes dejaron de moverse

Lo ejes dejaron de moverse

Category: General LinuxCNC Questions

That is a realtime network error.

1. Have you run a latency test on the PC?

2. What s PC hardware is being used?

3. Have you disabled all power management in the PC's BIOS?

4. What is the result of the command (typed in a terminal)

ip a

?


 
  • langdons
  • langdons
30 Jun 2025 15:31 - 02 Jul 2025 17:19
Replied by langdons on topic Puesta a tierra

Puesta a tierra

Category: General LinuxCNC Questions

If something needs 12V and 5V DC, having a 12V power supply and a 5V power supply with a common negative—effectively a single power supply with two output voltages—might make sense.

If the power supplies are powering seperate things, probably keep them isolated.

It all depends.
  • Johnnysacalu
  • Johnnysacalu
30 Jun 2025 14:31
Replied by Johnnysacalu on topic Lo ejes dejaron de moverse

Lo ejes dejaron de moverse

Category: General LinuxCNC Questions

 

He cambiado U5 y U7 ahora me salta este error
  • tommylight
  • tommylight's Avatar
30 Jun 2025 13:55
Replied by tommylight on topic Puesta a tierra

Puesta a tierra

Category: General LinuxCNC Questions

There are (often) cases where negative sides of power supplies must be wired together, but usually not at the power supply, it is done on equipment from one part to another. This avoids loops and keeps stuff at the same potential.
There are cases where this is not allowed at all.
So the short answer is yes and no, you have to know what you are dealing with to know if this can be done or not, and is not something you can just read on the internet, it requires deeper knowledge of the subject.
-
It is easier to answer if you give us exactly what you need to do.
  • langdons
  • langdons
30 Jun 2025 13:39
Replied by langdons on topic Puesta a tierra

Puesta a tierra

Category: General LinuxCNC Questions

If a power supply has a ground/earth screw, connect it to electrical ground.

A metal chassis should also be electrically grounded.

But power should be isolated.
  • langdons
  • langdons
30 Jun 2025 13:37
Replied by langdons on topic Puesta a tierra

Puesta a tierra

Category: General LinuxCNC Questions

Don't connect power supplies together.
  • kubes
  • kubes
30 Jun 2025 13:34

User error or a strange event on probing. Broken ruby tip.

Category: QtPyVCP

I was not implying there was an issue with the subroutines. While I don't use them as much as you, I have used them quite a bit without any problem. Additionally, my machine is a Bridgeport BOSS, which is quite rigid.

Having a log would provide the facts of what really happened, rather than relying on what I think I saw. Again, as probing has worked flawlessly, I was not 100% focused on the details. It looked like it triggered on the Z and kept going. I always test the probe connection prior to probing, with a manual trigger. So knowing if it triggered, how many times, the feedreate and movement, in chronological order, I could solve this definitively. I was thinking of saving the last 2-3 probes and rolling the logs so one the past probing, but not wasting disk space
Displaying 691 - 705 out of 25325 results.
Time to create page: 0.226 seconds
Powered by Kunena Forum