Advanced Search

Can you tell me what the name of the factory firmware is (.bin)?

I want to start all over again.

Also, is there somewhere that explains the difference between a .bin, .bit and .pin files?

Thank you,

Final update on the topic:
a replacement 7i84 just arrived and I connected it in the same way. With the new card all inputs and outputs are working properly. I can see the card in halshow and it just works

I will try to get my xml posted here tomorrow
the ECR86 say version 202!?
I started of by using rodw file he suggested
didn'work
after tried the ECR60 and did the modparameter stuff
afer tried the ECR86 and did the modparameter stuff
so far i only get errors
i believe you are at least 1 level up so i was hoping you could help

Never mind, I see the issue here. I believe the root problem is that even though I clicked "CLEAR", it is attempting to load the file I had open prior to clicking CLEAR after the single cut is over, which may or may not be out of bounds. It shouldn't do that, I will look into what got screwed up and push a fix ASAP.

SU 27?

it's you in the F16? small cockpit so im not sure F18 or F16 ...

did read almost half of the linuxcnc documentation and i didn't see anything that would answer my question ... are there basic rules / commands to start from in linuxcnc-ethercat....
I have been tru all this shite 20+years ago when i tried to get a twincat controlled plc to work... doesn't look like the information base to get stuff working has improved... digging thru the twincat2 information was a pain in the ass... trying to find answers in this forum ... vage information

That's probably expected.

You have about a 50% chance of an initial
runaway because the feedback direction is
wrong, that is you have positive feedback = runaway
rather than negative feedback = position control.

If the encoder direction is correct, you fix this by
changing the sign of the PWM scale.

Uhhhh, I think you’ve hit the nail on the head… How embarrassing…The 7i84 is powered by a 24V field power, but it's connected to a completely separate 24V rail (24V Logic, marked in red), while the relay board is connected to a different 24V source (marked in blue) with no common ground between them. I’ll fix that tomorrow. Thank you!

EDIT: Yes, that was the issue. Now the coolant pump is working. And after fixing a small mistake in my hal the spindle is now also starting. Now only the gear train remains (and the fourth axis...)

I have two identical PCs, same version (latest 2.9.3) of LinuxCNC, same F310.  One worked immediately - on the other, the F310 shows from lsusb (the output is identical on the first PC). But HAL config does not show the input pins on the second one.

I didn't do anything different in the installs.

Both are set to X mode

thank you, I hadn't noticed that was missing.

now, when activating the drivers, the motor goes into Z+ at high speed.
 

Hi...new to linuxcnc...just got up and running but now am looking to set up panel that shows 9 axis that can be jogged... am using 7i96s mesa with firmware that supports 9 axis but am lost as to configure panel through pncconf..??

Thanks for any help!!

Rick

Hello my friends, I made some changes to create some pins in the halui.cc file that I acquired on github, but I have no idea how to recompile it so that the changes are children, could anyone help me? Maybe give a step-by-step guide on how I can recompile. thank you in advance

The easiest fix is to install go -- `sudo apt install golang` will probably do the trick. Alternately, you can just ignore it, as it's only needed for some tools, not for the core of LCEC. You could even remove `lcec_configgen` from the `user:` target around line 83 in src/Makefile, plus the bit in `install-user` where it's installed, around line 92.

I don't think trying to make this part of the machine homing is a good idea. The main problem I see with trying to do this is: How could Linuxcnc know if the current Z position at switch on is high enough to safely move the XY over the probe position? There would be other difficulties that I don't see any good answer to as well but that one is might be the most insurmountable.

I think it would be better to configure the Z axis with a regular limit/home switch at the top of Z travel and home the machine in a conventional fashion. Then use your probe routine to set your tool and or workspace offsets for the Z.

There are multiple ways to configure your machine to automatically probe the Z at tool changes. One of the ways that is well documented is to remap the M6 code to do your probing routine. Another very simple option would be to simply write an o-code subroutine that you insert immediately after tool changes in your g-code files.

You can specify subroutine storage directories in the ini file of your config. And since they are simply ordinary computer files, you can protect them with the usual file write protection settings and file permissions available in Linux.