Advanced Search

but does it hurt to have it there?

That's a matter of opinion. My opinion is that I don't like it there. I'm very conservative and I don't like a lot of change.

We could also ask ourselves if the display of G-codes (and maybe Tool Information as well) is necessary in manual mode.

For example, this is needed to check whether G43, or G49, or G54 or G55 is active. Next, in manual mode, I check the Z-axis compensation. Some users use multiple compensations for one tool. For example, for T6, they use G43 H106 or G43 H206. Next, the manual mode window is the window that the user will see immediately after selecting a tool in the tooltable.

Could be, but I can't figure out where it's coming from, so looks like I'm stuck with a temporary fix of a possible temporary fix for now.

I remember Python giving me so much grief over the tabs and spaces in my first year of learning to program! At least these days IDEs take care of that problem.

C just went completely over my head when I tried to learn it. I can mostly read it but I cannot write anything in C, it's pretty frustrating

zz912 wrote:

Your answer is a technical explanation of why this is the case. However, I look at it from a user perspective. I take it that there is unnecessary information in manual and MDI mode. I understand that removing this is extra work, but it is not unsolvable.

Sure I can hide it in other modes than auto, but does it hurt to have it there?

We could also ask ourselves if the display of G-codes (and maybe Tool Information as well) is necessary in manual mode.

I think the switching of the visibility would confuse the user more than it would help. At least now as we have enough space.

Was able to build and test it. Interesting.
There is the problem with the size of normal data types.
But also with compound variables/pdos like an uint32 that is really 12 bits input and 20 bits of nothing. Can be handled separately in a hal component to create individual pins I guess, but adds to it.
The naming of the pins is horrible, but you have all the info from the drive so can be fixed.
It's easy to compare to the situation with lcec_conf that offers solutions to I think all situations.
But adds its own complexity and isn't ideal. Too many details often go wrong.
You made a start with the ethercat_twincat configurator, that looks like an appealing way forward.

For the Linuxcnc Raspberry Pi images just don't do dist-upgrade, it will break things, this has been proven.

You get get away without doing any kind of upgrade.

If you are worried about security, updates are only a small part of the picture. The first step should always be physical security, which should be the number one priority with a computer running a cnc machine.I'd take data loss over damage to a cnc machine any day of the week, you can't back up a cnc machine.

I would still appreciate knowing how to call anyone of these routines without going through the entire program.

You can call any subroutine in a loaded program from MDI (eg 'o100 call')

Also how to set the Z after the tool change.

Do you mean the tool-length offset or the work-offset?

The currently active work offset can be changed like this:
'G10 L20 P0 z123'

What about the "rawcounts"? when i quickly had a look at them in halscope they seemed to have "0" at a fixed location, do you think that's something i could use in some way?

langdons wrote:

Is dist-upgrade ever a good idea?

Yes, when you download an ISO, it might be several months old, so that will update to the latest stuff for that distro, including kernels and stuff that "might break things".

pgf wrote:

p.s. Best tech support ever...

Yes he/it is.

The STEP/DIR output voltage will be the 7I96 5V supply voltage
if there is no load. Any load will lower the output voltage.
So it could be low supply voltage, or a load on the output
The output resistance is around 50 Ohms so a 10 mA load will drop
the output voltage by about 0.5V

ahhh thanks pete!  i just came across that just a few minutes ago. i thought that looked suspect. must be a bug in jt’s config tool because thats straight out of mesaCT. 

quick question, any reason i cant get more than 4.45v out of my pwm?  ive checked everything on the hardware side and its all good there. no matter what i do, i cant get more than 4.45v max from the pwm

Dont merge anything just yet. me and my friend have spent the last 3 days trying to figure out the shit outta this problem. we have environment configured, we can switch uart, but we are very stuck and out of ideas. We are trying to switch SPI channels from 1 to 2 and/or 4, but we just dont know what variable we are missing/not configured. It works mostly but the MOSI doesnt seem to work but the MISO does. SPI1 works fine, but we cant figure out how to switch to 2

github.com/cakeslob/Remora-STM32H7xx-PIO/tree/h723
github.com/cakeslob/Remora-STM32H7xx-PIO/tree/spi4

No outputs are GPIO

7I96 isolated output hal pins are:

hm2_7i96s.0.ssr.00.out-00
hm2_7i96s.0.ssr.00.out-01
hm2_7i96s.0.ssr.00.out-02
hm2_7i96s.0.ssr.00.out-03
hm2_7i96s.0.ssr.00.out-04
hm2_7i96s.0.ssr.00.out-05
 

If you want help, you will have to upload your hal & ini files, otherwise no one knows exactly what you are doing.

Heh. It's as if you actually know a lot about this, and have been doing it a long time.

I changed hm2_7i96.0.dpll.01.timer-us from -50 to -250, and the symptom went away. (First try, I changed all 4 dpll values by -200, but it turned out changing the others wasn't needed. I'm guessing they're not used?)

Thanks! Oh -- also, hm2_7i96.0.packet-error-total stays 0.

paul
p.s. Best tech support ever...