Advanced Search

mesambccc compiles the modbus device(s) specific xml source file
to data files that hm2_modbus uses.

Typical mesambcc usage would be something like:

mesambccc  -o ~/linuxcnc/configs/mb25ioc32.mbccb mb25ioc32.mbccs

Where mb25ioc32.mbccs is the xml source file and mb25ioc32.mbccb is the resulting
data file that the driver uses. 

Hal file setup is described in the hm2_modbus manual page:

man hm2_modbus

A minimal 25IOC32 xml source file looks like this:

<mesamodbus baudrate="9600" parity="N" interval="1000" >
 <devices>
  <device name="mb25ioc32" address="0x01"/>
 </devices>
 <commands>
  <command device="mb25ioc32" address="0x0000" function="R_INPUTS" name="input" count="32" />
  <command device="mb25ioc32" address="0x0000" function="W_COILS" name="output" count="32" resend="true" />
 </commands>
</mesamodbus>



 

Because I use a control panel with all my machines, I utilize many halui signals for program start/stop, spindle start/stop, overrides, etc.

I would try to avoid using halui and use the pins created by gmoccapy and use a hal structure to only enable them when auto mode is on.

 

www.linuxcnc.org/docs/html//gui/gmoccapy.html#_hal_pins

 

Hello,

I ran a test again—maybe it will help someone solve the problem.
The system configuration is as follows:

Debian 12
LinuxCNC 2.10.0-pre0
Gmoccapy 3.5
Configuration generated with Stepgen (basic 3-axis mill).

Because I use a control panel with all my machines, I utilize many halui signals for program start/stop, spindle start/stop, overrides, etc.
As you can see in the video, the spindle signals (halui.spindle.0.is-on, spindle.0.forward/reverse) work correctly when the program is started by clicking the Start/Stop buttons in the Gmoccapy interface, and the number of lines in ngc file is fewer than ~1100.

However, when I load longer files than 1100 lines (attached a test file) and use halui.program.start/stop signals, the spindle signals behave differently and cause the spindle motor to restart from the HAL program.
I believe the issue is related to halui.program.stop. For example, if I start the program using the Gmoccapy button and then stop it using halui.program.stop, the problem still occurs.
But if I start the program using halui.program.start and stop it using the Gmoccapy Stop button, the problem does not occur.

Interestingly, the issue disappears when I reduce the number of lines in the program to below approximately 1100 lines (the test .ngc file originally had around 12,000 lines).

As shown in the video, the spindle signals reset at program stop and—though not every time, in about 8 out of 10 cases—they are set again shortly afterward and remain true.
When using only Gmoccapy buttons, the signals reset, generate a short pulse a bit later, and then reset again.
If the .ngc file contains fewer than ~1100 lines, the spindle signals reset at program stop and do not set again—no pulse is generated either.

Files and video:
drive.google.com/drive/folders/1MjqY3XpM...5T-rd4Og?usp=sharing


 

pgf wrote:

Gave the new axis-like UI a spin this morning. Looks and feels good. I noticed the buttons (e-stop and machine-on, in particular) don't have the 3D "I'm pushed" look when they're pushed released. A small thing, but there's no other visual way to tell the state.

I need to come up to speed on modifying these UIs, so I can make changes and flesh it out. (I know, I know... watch the videos. ) The big missing piece for me right now is a probing/touch-off screen. My current probing setup is pyvcp, so clearly it will need to be redone. But I'll bet you already have fully functional probe screens just waiting to be dropped in.
 

The Touch Probe 3 example has full working probe routines that you can drag and drop onto your gui.


JT

Did some work on the toolbar toolbuttons...



JT

Have a look.
As I said I use a M2 realtek nic on top. Isolcpus=1 works for me, but it depends on the build in cpu. So you have to test. Also be aware to make the lines in the network interface for the intel nic. Other than that, as one can see the m710q can run a read time of 200k ticks @ nearly 3GHz. And the jitter is quite good for eth mesa cards.

Hi Todd,
I’ve checked everything—the only thing left is the motor encoder, and a lot of people, including an electrician, told me it’s likely the problem. I’ve tested all the cables (several times), the controller, and I’ve even done parameter resets. So, It must be the encoder , because i've powered the motor with a  power supply and it works.Just to clarify: I’m not doing the retrofit only for  the motor. It’s because I’ve been talking to a guy who used to work on the same machine, and he said there are serious issues with the Z axis ,it doesn’t save its position. Actually, before the machine broke, I had experienced this issue myself.Over the last few days, I did some research and found a good shop online Variumetrum and  i have done some research and seem's good so here my choices:

• 3 x Leadshine ELM1 750W with brake
• 3 x Leadshine AC Servodrive EL6 750W
• 1 x Mesa 7I76EU(not from the same shop)

On the old machine i've Sanyo Denki 500W  DC80 Model 850T-0123EL7 , brushed motor .
Let me know what you think!

Ps- I've only to think to the z axis and than i can buy all of them.

Thx for your help! I hope that the usb-rs485 solution will work as well as ethercat would do.
I had a closer look on the manual of the Optidrive and unfortunately they don`t offer an ethercat interface for the E3 Series. It has multiple protocols on board but not ethercat. Can open is available and Beckhoff offers a Can open module - but as an absolute newbie it will be impossible to implement it I guess.

My experience with issues with servos on older machines, has been. probably 70% of the time servo problems are usually cabling issues, about 20% a problem with the drive, and maybe 10% a motor problem. Intermittent problems are almost always cable related, and most servo motor alarms from the drive are also usually cabling issues. Check any cables that move or are flexed regularly, as well as connections at plugs, cord grips, and pinch points.

As to servo replacement options, I think Delta is nice, but Leadshine is nearly as good. Be careful of Chinese knockoffs if buying from questionable 3rd party venders.

Currently, my configuration is rather messy. I will choose to upload it after I have some time to tidy it up later. The current problem has been largely identified. By analyzing the PDO data from different platforms, I identified some subtle differences. I then reported the bugs to the manufacturer and waited for them to provide a new firmware. Once the new firmware is ready, I will post the detailed differences here.

Hey guys, I'm pretty new to all this coding jazz, but I've fumbled my way through a bit so far. I'm using a NVEM V2 board with the NVMPG to control a RongFu RF31 i have retro fitted with some stepper/servos. So far i can move the X Y Z axes accurately using the key board and the NVMPG, I can also select axes with the NVMPG and I'm seeing all the inputs work in the Hal Configuration. But now I'm at a loss at how to modify the Hal file to get those inputs to function, especially the estop. I'm using a N/O estop switch and it's switching remora.input.04 to false (.04.not to True) when hit.
What do i need to add to the Remora-nvem.hal file to make it work?
Or does any one have an already working .Hal file for the NVEM V2 with limit switches and other typical milling functions i could look over?
 


Thanks
 

Thanks for the quick answer, a little bit busy at work, so I am somewhat slow.

My problem with that 5V Output was, that it, oddly specific, says 5.2V. Since the documentation mentions that the inputs U1, U2 have 1% error (when using 0-5V), I thought 5% more voltage is a lot...

The specs mention, that the "resistance of the input" needs to be above 1k. I could not find any specifics in the Mesa manual regarding that, but the "SPINOUT" should be high enough impedance?

BTW, I have no Idea why he is using 2U, instead of 1U. The two inputs seem to be equal. A1 seems to be a fault indicator, as far as I undestand.

Doesnt really matter. 100 is enough an you will have less frequency and therefor less emf topics.

I assume we are speaking of an non hf spindle right? So 6000 rpm results in 100 rps and therefor to 10.000 ppr or 40.000 cpr. So totally easy to handle.

But in this case a 600 encoder also will work efortless.

Hi Tommy.

I implemented the changes you suggested except for those done on the Bios as I do not have access to it over AnyDesk.
After implementing the machine would home correctly as normal, but when running to a set distance the arm would halt after moving about 20 mm and give an error, "joint 0 following error" and this process of moving slightly and giving error happens every time any distance is entered. I also received latency warnings for 100000. I have attached a picture of the errors.

I reverted the settings back one by one and machine ran as it did before only after all changes were reverted. These were the changes I made:

• Base_Period = 100000 >>> set back to 500
• Drive microstepping = 1600 >>> set back to 2000 pul/rev 
• Parport reset time = 10000 >>> set back to 500
• I added STEP_SPACE and STEP_TIME to the "EMCMOT" section as I did not already have it in the ini file. STEP_SPACE & STEP_TIME = 0.00001 >>> I removed these two settings after.
  
  Any thoughts on how to proceed? Thank you for your input so far

Yes, that is my alterego on github.