Advanced Search

Perfect, thank you, that helps me prove some of my suspicions. I have to dig more, seems like I didn't understand the Omron data sheet. Apparently you can select the PDO's you want mapped to SM 2&3, through some registers.

"The PDO mapping to be used is specified in Sync Manager 2 PDO Assignment (1C12 hex) and Sync Manager 3 PDO Assignment (1C13 hex)."

I would be surprised if you don't get "83" errors. I get alot of unmatched datagrams but it will go into "op" mode. It might have to do with the actual PDO assignment register.

Yours might work because you have different PDO's defined, however it also states:
"Since the mappings you changed are not saved in EEPROM, you must specify objects each time you turn ON the power of the G5-series Servo Drive in order to use the mapping other than the default setting."

I did not see any SDOconfig for those registers, so I will assume you have the "default" values, which I will confirm on my drive:

Drive Firmware version v2.14 ( ethercat upload -p3 --type string 0x100a 0)
My Default values are:
Sync Manager 2 PDO Assignment Register readings
ethercat upload -p3 0x1C12 0 = 0
ethercat upload -p3 0x1C12 1 = 0x1701
ethercat upload -p3 0x1C12 2 = 0x0000
Sync Manager 3 PDO Assigment Register readings
ethercat upload -p3 0x1C13 0 = 0x1
ethercat upload -p3 0x1C13 1 = 0x1b01
ethercat upload -p3 0x1C13 2 = 0x0000

So we can see the hal file you are using is incorrect.
Unless you set these up somewhere else, but I wasn't able to see it in the XML settings

yours have 0x1702 & 0x1b04 which are mixed matched, not sure if thats allowed. By default it should be 0x1701 & 0x1b01

Ah so the variable PDO mapping makes sense now. You can assign whatever PDO's you want, you set the Assignment registers to 0x1600 & 0x1A00 respectively. If I can get that to work I will post a xml file for that example as well.

To the OP I'm sorry you're having to deal with some useless posts from Langdon's.
Yes it is good to connect with other users that are local to your region.

Depends where you live in this big old world. I've seen 7i92 clones boards on AliExpress that are the same as the original 7i92. To get one Down Under is more or less 80 - 100 AUD, which is more or less the postage alone.
Now here's comes what would be done hypocrisy on my part. Whilst I have built a 7c81 / 7i90 clone using a Spartan 6 Dev board and some custom PCBs, I wouldn't buy a clone from AliExpress, due to the Mesa cards I've bought being solid and reliable and PCW being so supportive to all and the help he gave with my endeavours. I know it sounds strange.
I feel these boards and people asking for support may be a topic that could be divisive.

I'm guessing your previous install was a version prior to Python 3. The py2 versions worked with a pip install as run in place where apt installs in root. Your custom py file should still work though. It may be a py2 file needed updating to py3?

Thanks for the svg -> bitmap conversion into the thread. When I get a chance, I will try running a script to process all the sim configs.

OK, these errors should be resolved with this  forum.linuxcnc.org/42-deutsch/55509-inst...bleme?start=0#323051

Thnks a lot

A reinstall unfortunately does not solve the issue. I am also not sure that this is a new problem. It looks like the running version is probe-basic_0.5.3-216. We never tried using the probing part of the interface until a few days ago. After the probing routine completes, the ui stays in the busy state indefinitely if I had it set to update the WCO. If it is only set to measure, it works fine. I can find no significant differences between the old and the updated probing routines. Also, probing with my own custom routines works fine. It is only when I click a probing routine on the probing tab with it set to update the WCO that it locks up. If I comment out the G10 line, the ui does not stay locked. I have tried running linuxcnc from the terminal to see if there is any debug output but no luck there either.

I figured that support from the people who make it for what appears to be a bug in a version from 2023 would be a long shot. It is from before installing from apt was even an option. There are also a few modifications I no longer have to do because they have become features. I have not connected the new version to the machine to test if probing behaves the same way yet. Wanted to make sure I could get everything to behave the way we have trained people. I have a little mini pc set aside to for that once I get a copy of the config modified for our machine.

Appreciate that it can be tiresome to see the same stuff repeatedly. Everyone is at a different point in their journey of learning.

OK, installation is done.
At the moment the latency test looks like this:
 

The only thing is that i allways get the same depending-problems, so i can not upgrade the kernel.
 

Can someone help me here..
Thanks a lot
Jens

Reply redacted.

I would venture a guess at some 20 members here being from Poland, so there is always a chance.
Also Proma is from Poland and Tomaszh is here often, lately with new capacitive sensors, and they also do THC and some controllers, see Proma Elektronika (yes, with K )
-
Now, what exactly do you need help with?

I can guarantee you that there are many users in Poland with that equipment.
But if they are here and see this request is another thing.

Perhaps a reinstall of the same version is the solution?

Is the locking up after probing a version-related problem?

Sorry about getting mad, it just annoys me when people totally reinstall over their current system and then can't go back if stuff breaks.

I did not intend to make anybody feel dumb.

Reply redacted.

This is described on page 11 of the 7I96S manual

basically:

RX-/TX- connect to RS-485 "A"
RX+/TX+ connect to RS-485 "B"
W7 right
 

I have a 7i96s rev E that I'm trying to connect to a WJ200 VFD. The VFD  uses a 2-wire RS485 interface with pins labeled SN and SP.

How should I connect this to the 7i96s i/o pins?  What position should W7 be in? 

Thanks,
BR