Advanced Search

actually I found out it was caused by a tool being called that doesn't exist, so it cancelled the file load

I am stuck at the same point again. I was leaning heavily on LLM's to get me this far, but I think some human common sense and experience might be required here.
Please, If anyone can shed some light as to what might be required here, it would be much appreciated.
 

I think I understand the width and scale now, I have illustrated my understanding in the pictures attached.  If you could confirm that those measurements are the correct ones for the width and scale parameters that would be amazing.

Our problem is the understanding of how the carousel component integrates with the hardware, for example how come some people leave pins or parameters out. And what is carousel-lock and unlock and how does it relate to the component. 

Also my illustration was fast it is not to scale unfortunately, so I included a photo of the actual carousel.  
Thank you

 

unknown wrote:

You didn't by chance use the new trixie image on the downloads page did you ?
 

Actually, yes I did... Shouldn't I?

It is definitely a python 3 version. If I remember correctly, it was shortly after the pip install method stopped working and the install documentation was in a little bit of flux at the time. The new version I am working on does not throw an error when I try to disable a button, It just does nothing.

I will preface this next part by saying that I have just enough skill in reading and understanding code to get into trouble. I haven't used AI stuff because I don't have the skill to double check it. I found when digging through the source that sub call buttons reference issue_mdi.bindOk which references some stuff in the status plugin.

With guess and check I have found that on SubCallButtons I can do this:

STATUS.homed.onValueChanged(lambda: self.probe_spindle_nose_subcallbutton.setEnabled(False))

With this added to the top section of the file:

STATUS = getPlugin('status')

I don't know if this is a good way to do it but it does disable the button.

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

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.