Hello,

I recently upgraded LinuxCNC from version 2.9.4 to 2.9.8 and updated Probe Basic to the latest version as well. I'm currently experiencing an issue where the DRO display in the Probe Basic GUI appears blank.

Has anyone encountered this before and could point me in the right direction to find a fix? The Probe Basic simulation configuration works fine and the DRO is visible there, which leads me to believe my configuration file is the main culprit. That said, this same configuration worked without issues prior to the update.

I've attached the machine HAL and INI files in case they're helpful.

I shoukd have mentioned but the signal for the servos is +-15V, is there a good work aroud to up the V or something

Im working on an old kondia fv-1 mill thats got an outdated cnc system, my plan is to hook the motors stright into a Linuxcnc set up and get rid of the old computer. Iv got 3 servo drivers to give signal too and have been trying to find a mesa card that can do that, im guess im under the wrong impression on whats its doing but iv seen a lot of 2-3 card set ups, im looking for a way to simply plug the servo drivers into a card that sends them a singal with the pc. Do i need that FPGA plus motion control card? Or can i just get by with one od the FPGA cards? Again im probobly confused on what thees cards are actually doing, iv mainly messed with old 3d printers, any explanations would be appreciated 

corrected

@andrax
How do you know that the vid and pid are wrong? I have set them in the .xml file as per the manufacturer .xml when I created the configuration. Attached is the .xml file.

The "dmesg | grep ethercat" still does not seem to work, I executed the command sequence you posted and it just outputs a new row in the terminal.

I am still unaware why the synchronization error keeps appearing, cables are changed and I also have grounding on the metal parts of the bench.

Perhaps, there are some settings in the servo itself that need to be configured. I still think about the fixed and variable PDO mapping, if it could be the reason for this behaviour. There is a warning that says - 1 datagram UNMATCHED!.



 

When you say the motor moves, are you saying the DRO is changing
when no commanded motion is requested?

Do you get a following error?
 

It would be nice to have a simple_xyz_tp.comp component to support linear interpolation and be independent of the main TP.

I think this is a simple task for extending the simple_tp component, where smoothing and arcs are not required.

Did you verify that all home switch inputs work as expected in halshow?
that is, the motions home  switch pins (like joint.0.home-sw-in ) change from
red to yellow when activated.

You might also check that there is no noise on the switch inputs.
(setting halscope to trigger on the switch active level can catch single cycle noise pulses)


 

Can you post your PINxxxx.vhd file

 I can take a look
 

You are trying to control a hal pin, so you will want to use a HalButton from the custom widgets tree. the halpin will have the pinBaseName property you need to set for the button's connection to your licht net. see image below for references:

 



the button color can be style in the stylesheet (see image below) using the following color connections:

 



The button probe_basic_postgui.hal file connection code is as follows:

once done you should have something that works like this gif below, but for your physical light:

 

 

1) It may not be a good idea to divide the architecture of a single module too much. This can cause unnecessary complications in the connections between them and race conditions between components...  For example, the state machine of the “homemode” module in some situations cyclically processes several states in one cycle, thanks to its flat structure, which would be difficult to do if it were broken down into modules.


2)

gantry_manager.comp
Possible responsibilities:
- synchronized homing of multiple drives
- gantry squaring

I think this should be handled by the built-in homing and kinematic module, regardless of the communication bus.

I recently encountered this using ethercat drives with absolute encoders - it is already partially successful. 
Alignment occurs during the homing procedure when jointY1 and joint Y2 move independently and synchronously (home sequence) by calling free_tp,
but requires a revision of the procedure for HOME_ABSOLUTE_ENCODER, which is used by cia402/ethercat ( github.com/LinuxCNC/linuxcnc/pull/3774/c...be947439e20fc5da9825 ), to prepare it for correct communication with the cia402 state machine

as a result, squaring control should take place in the trivkins module where, when declaring KINS=XYYZ, the connection is established 
joints[1] = pos->tran.y
joints[2] = pos->tran.y

I don't see the need for another layer  “motion -> trivkins -> gantry.comp -> pid -> cia402 ->lcec”   since we already have independent joints, each of which is connected to feedback for tracking following error.

I'm convinced extrajoints handles such a case. It can even move multiple joints at the same time, they're just not synced with each other in any way unless extra hal logic is used to interpolate moves, which you don't need here.