The PKTUART pins are on the two RS-485 capable 7I52 channels (the ones with TX Enables)

 

Jerk limit to the point of seeing your machine move sluggishly? Béziers are Just to be able to get better cornering speeds, because tangent arcs are not optimal for covering with jerk limit.
Scope of planner type 1 is jerk limit to a crawl if necessary? Like the 0.0001 G2 curves that ruediger123 shared. Done with small G64P tolerance, I agree those should just slow down as much as you need to follow path within tolerance, BUT for a square with NO programmed corners, blend with arcs and parabolas are acceptable? Just slow down as much as we need to follow the blend arc? Point cloud line to line is another issue, slow down to keep everything smooth? but then you will see the machine smoothly follow your point cloud, but it will speed up and slow down, speed up and slow down, because we are not trying to maintain velocity, we are sacrificing it, and because we work mostly segment by segment, I don't see an easy way out, Béziers could give us a better path, but we will need to figure out where and how to stitch them smoothly. and how to do it while the machine is in execution, we can't plan the whole thing offline.

Greetings,

I too have a fc01 and have just started to try rs485. I have had no luck using the python code supplied from the manufacturer. One inconsistency that i noticed in their code as well as the code in this thread is:

The parameter is set P14.02 = 0 , from the manual p64 this is "0: No check (N,8,1)for RTU" but in the code above parity is specified as E.

Sorry if I have missed something. Thanks bruce

I will to get your python working on my pi5 or my desktop.

After a quick look it seems the deasda driver includes a layer that kind of resembles the cia402 driver.
The drive itself is cia402.
deasda gives a large set of hal pins, with "generic" and cia402 one needs to puzzle that together self.

These drivers don't do very much more than translate between pdos and hal names, there is no real processing.
Some logic is in there, but there is no performance reason to select one or the other.


 

Wow, You are amazing Thank You .Drive is communicating with LCNC.
Next step is to create proper config.I will do an update in a few days.

Yes, now understandable.
You see the problem? lcec.0.0.cia-statusword
Numbering is lcec.<master id>.<slave id>.variable-name
Your slave id is number 1, at least that's what it says in ethercat-conf.xml
Must match numbering from "ethercat slaves"

OK I hope that now is much more clear, thanks.

Please revise your post to get rid of the rubbish and lets start again

Gogonfa wrote:

Hi Rod,

Is there a big difference between using the CiA 402 driver and the also implemented Delta ASDA driver (DEASDA) with Delta drives?

I don't really know. I've always chosen CIA402 devices because they are a known quantity. (eg I'm risk averse) There are some drivers for other hardware which I would include in my list but I have no experience.

I thought jerk limiting was purely about acceleration. To extend it to varying the path seems to me is really scope creep. Get it working without changing the path and include path optimisations at a future time and write better gcode for now.

jerk limiting may permit higher maximum acceleration. Currently MAX_ACELERATION is set from a combination of motor dynamics and physics by the machine builder Eg the inertia in a heavy moving table may require a lower acceleration than what the motors are capable of so they are not overcome by inertia on deceleration and cause following errors. Its probably valid on a jerk limited machine to increase acceleration. In this context, some violations may be valid.

Hi Rod,

Is there a big difference between using the CiA 402 driver and the also implemented Delta ASDA driver (DEASDA) with Delta drives?

Hallo Hakan, thanks for Your response .I do like You sad but after removing sim files there is another problem like in the picture
 
 Only for another try i create separate second config, files like .hal , .xml are exactly the same as before., but there is simlar problem like in the picture
My goal for that moment is only confirm that drive is talking to LCNC.Thanks again. 

 
 
 

Hello,

It would be very kind and helpful if you could create a bitfile for a 7I97, 7i89, and 7iA0.

Currently, not all 14 encoder inputs are needed; this is just a preparation for glass scales. Currently, the encoder for the handwheel would be connected there.
The 7iA0 is to be connected to the 7i89 via the serial interface.

I managed to establish a connection in the old configuration of 7i97 + 7i74 and 7iA0, and the watchdog was gone. But this configuration no longer exists.

Sure I will let you know about the finished Project

Excellent! Thanks for not giving up.

In this kind of trouble shooting details really matter.
qtdragon is not the same as qtdragon_hd, error messages need to be quoted exactly etc.

When you get everything finished I hope you post a pic of your creation.