My personal opinion is to default to #1. But as G64P tolerance increases allow more path tolerance so that velocity deviation can decrees.

i found it i got my clock.
i needed this two line:
setp hm2_5i25.0.biss.00.timer-number 1
setp hm2_5i25.0.biss.00.frequency-khz 8000.
i just want to know if it is ok to have 10 volt of amplitude between -5 clk- and +5 clk+ with spike to -10 +10 v? seem a bit much for a clock, WIll test other cable i may have made a mistake here.

Huh, thought I'd posted again last thing last night but it doesn't seem to have taken.

We tried the 7i80HD-25 card with the -25 version of the firmware you sent, and with this in the system, the encoder ports are being read as expected (apart from how Yaskawa servopack C-channel vs Z-channel isn't as expected at all).

I would be grateful if you could send the firmware for that card including: 6x analogue servo, 6x encoder, 2x pktuart and 2x sserial modules, for 7i80HD-25, 7i48, 7i52 combination.

Thanks in advance!

Probably more like this where a bitmap exists. Note that in places its padded with unused bits  

i am not making any progress so let take a step back.
i use a bit file PIN_7I76_7I74BISS3D_34 With the biss signal assigned to a 7i74 plugged on the port P2 with the pin configuration :
        IOPortTag & x"00" & BISSTag  & BISSDataPin,             -- I/O 17    PIN 1
        IOPortTag & x"01" & BISSTag  & BISSDataPin,             -- I/O 18    PIN 14
        IOPortTag & x"02" & BISSTag  & BISSDataPin,             -- I/O 19    PIN 2
        IOPortTag & x"00" & NullTag & x"00",                    -- I/O 20    PIN 15
        IOPortTag & x"00" & BISSTag  & BISSClkPin,            -- I/O 21    PIN 3
        IOPortTag & x"01" & BISSTag  & BISSClkPin,            -- I/O 22    PIN 16
        IOPortTag & x"02" & BISSTag  & BISSClkPin,            -- I/O 23    PIN 4
I dont understand yet why we have 3 pin for data and 3 for clock but its fine.

the objective now is to get the system to produce at least a clock. with the cnc project running i tried to locate where the clock where available but nothing. I tested each port rj45 on my 7i74 and even the pin from the cable between my two card and nothing relevant. i got power (5v) some signal but no clock. do i need a command in hal/init /bit/god? to indicate that the signal should be active?

You still use hal files for simulation. Delete all hal files with sim in the name from the ini file.
 
 

Try Note the bit.

Not obvious what's wrong.
Start linuxcnc, try to move, stop linuxcnc. Then show the output of the command "sudo dmesg | tail -30"
Also the output from the linuxcnc start command.

I see you asked for something different in the second post. 
Take the ini file from one of the simulated machines and change the ini file to include the cia402.hal from: here  github.com/dbraun1981/hal-cia402/tree/main/example

You can try with the syncToRefClock option or if you have an old version of lcec, a minus sign  

Das Forum war gestern so laggy, da kam connection_timed_out bevor die aktuelle Datei hochgeladen war.

I've decided to release a 'Starter Edition' for Arduino Uno to let everyone test the driver's performance. Details and download link are available in the technical thread here:
forum.linuxcnc.org/27-driver-boards/5823...cal-feedback-request

Quick update: I’ve just finished the 'io_decoder _eval' firmware for Arduino Uno.
I'm currently drafting a quick-start guide and a wiring diagram to make the testing process as smooth as possible for everyone.
I expect to release the package (firmware + documentation) this weekend.

Stay tuned!

phino wrote:

To clarify, the suggestion was not to validate use with Aerotech controllers. The thought was just that it should be simple enough to configure the analog input/output to use the sensor with the existing system available. That would allow testing the sensor's functionality under different conditions, if that would be of use to you.

It seems that I may not have fully understood what you expect and how you would like to test it.

it is compatible with mesa default setup, but you need add the jerk parameters in the ini file, look at the axis_mm_scurve.ini file


I wanted some feedback from the community about s-curve, there a few considerations to make, not just jerk spikes

I think there are some choices to make, when trying to respect jerk limits, we can:

1 - Slow down at curvature changes: reduce Vel so the centripetal acceleration change is manageable. (this defeats high-speed machining)

2 - Modify the geometry: insert transition curves (clothoids, Bezier, splines) that have gradually changing curvature. This eliminates the discontinuity but changes the path. (when G64 Px is too small you will see jerk spikes)

3 - Accept the spike: the programmed path has a curvature discontinuity, so the motion will too.

There is no fourth option. You cannot maintain velocity, follow the exact programmed path, AND have smooth jerk. we need pick two.

ok let's try this:
Since your handler isn't modified, replace it with the one I supplied. It's ok to keep your modified ui file in the config folder.
Of course you still need the INI changes.

If you do want to modify the original handler for other reasons, that can be done, you just need to add most of the code in the handler I supplied.

Just to be complete Qtvcp will use the default handler and ui files unless it find either or both in your config folder.
In the case of the handler file, it's possible to make a special handler file that loads the original and then extend it.
This is nice as if the handler gets updated in linuxcnc, you will get those changes and then the local changes are added on top.