Advanced Search

Thanks for the tip. It was loading the wrong file.

HAL files specified in the HALFILES variable are found using a search. If the named file is found in the directory containing the INI file, it is used. If the named file is not found in this INI file directory, a search is made using a system library of HAL files.

tommylight wrote:

Yes it is as the change must also be reflected in HAL, so it would require having two of the same configs with and without the inverted input, very easy to do and use, but can not be used if both are to be used in the same run.
NO or NC does not matter much, but having both NC would make it possible to use the same input when wired in series.

Today the z probe arrived, I connected it to pin 11 which is where I have the 3d probe. In the hall file I have removed the "-not" so that it works like NC. I have configured it as a basic probe and it works correctly.

Now what I need is to connect it to the same input as the 3d probe (the 3d probe is NO) if possible. I have searched for information but the truth is that I have no idea how to do it.

Tonight i poked around in the rtapi & hal source code.
To my suprise was able to load multiple instances of hal, each using their own memory region.

file : hal_priv.h
Add a few define's


file : hal_lib.c
Normally it uses : int init_hal_data() ; Then it uses a previous declared pointer hal_data->....
We cannot use this for initializing multiple instances. Solution is to change the function a little bit.


new file : hal_instances.c
This file creates the hal instances. It allocates the memory for each instance.
Then it initializes each hal_data_t struct using the above function : int init_hal_data_struct(hal_data_t *data) ;


Then added a init function to halcommand.
Then you can type ~./bin/halcmd init
Then in terminal :
user@pc:~/hal/bin$ ./halcmd init
hal init instances.
Initializing HAL instances...
Successfully allocated shared memory at address: 0x7f0557fe8120
Each hal_data_t instance requires 288 bytes of memory
Initializing HAL instance 0 at address: 0x7f0557fe8120
Successfully initialized HAL instance 0
Initializing HAL instance 1 at address: 0x7f0557fe8240
Successfully initialized HAL instance 1
Initializing HAL instance 2 at address: 0x7f0557fe8360
Successfully initialized HAL instance 2
Initializing HAL instance 3 at address: 0x7f0557fe8480
Successfully initialized HAL instance 3
Initializing HAL instance 4 at address: 0x7f0557fe85a0
Successfully initialized HAL instance 4
Initializing HAL instance 5 at address: 0x7f0557fe86c0
Successfully initialized HAL instance 5
Initializing HAL instance 6 at address: 0x7f0557fe87e0
Successfully initialized HAL instance 6
Initializing HAL instance 7 at address: 0x7f0557fe8900
Successfully initialized HAL instance 7
Initializing HAL instance 8 at address: 0x7f0557fe8a20
Successfully initialized HAL instance 8
Initializing HAL instance 9 at address: 0x7f0557fe8b40
Successfully initialized HAL instance 9
Total memory used for HAL instances: 2880 bytes
All HAL instances initialized successfully.

So far it seems to work. But now we must dive a little deeper.
What should be the next step? Maybe do a halcmd show..

This is for example the  ~./bin/halcmd show function


In above function hal_data->.... is used, this is just one hal instance pointer.
in the file hal_priv.h its declared : extern hal_data_t *hal_data;

So now we know we just have to implement our instance regions.
hal_data_t *hal_instances[MAX_HAL_INSTANCES];

Will try to test if this works.

If you did configure as suggested, chances are one of your Y joints is spinning in the wrong direction, the one that moves after homing is OK, the other should be reversed, but beware as that requires reversing the search and maybe latch velocity directions.
Can be done easily by adding or removing - in front of scale and home search and latch velocity for that joint in the ini file.
To me sure, make a new very basic config with only steppers, but choose two sets of step/dir signals for Y axis, save, start the config and jog SLOWLY the Y axis. Do both run in the same direction?

A 7I96S can replace a 7I76E if you can get by with the more limited I/O
(11 inputs and 6 outputs instead of 32 inputs and 16 outputs))

You can add a 7I84 to a 7I96S if you need additional I/O
(this adds 32 inputs and 16 outputs)

Also 7I76EUs should be available in about 4-6 weeks
(7I76EU is the universal output version of the 7I76E
that supports sourcing, sinking or push-pull outputs)

mBender wrote:

Below is the current set up as of last night. Bench testing worked as expected. It goes from there to a Parallel port break out board. This allwos me to use my machine with LinuxCNC and laserGRBL with just changing a plug. I tried to find out the current rating of the 3.3V and 5V power supply of the Tang Nano 9k. According to the schematics, it seems like that there is a TMI7003C DC/DC Step down, which gets it's 5V directly from the USB C port. If I read it correct, it can supply a max current of 1.5A total. That'a including the power for the FPGA,...It seems like the each Output of the Tang can drive up to 24mA. Which obviusley need to be deducted from the 1.5A plus the other current demands of the FPGA board. Still I believe there is plenty of current to drive secondary operations.The 1.8V needed for Bank 3 is not availbale at FPGA board. I was wondering if I could just use 1 or 2 1.8V outputs, set them pernantley to high and use them as supply voltage for any leverl shifter at Bank3. Opinions? 

 

My personal plan if I needed more gpio was to ignore the 1.8v pins and using the 3.3v pins either use a shift register, see if I could add i2c GPIO expansion support such as the mcp23017, or reserve the FPGA purely for estop, home pins, and steppers and use something else for things like MPG controls and such. github.com/wezhunter/ESP32_LinuxCNC_MotionController_RealTime perhaps, since I have a pile of esp32S2's around. 
I also ended up with a XHC WHB04B-6 wireless MPG that currently satisfies 90% of my control needs, so I don't have a lot of willpower to make a UI that needs a lot of GPIO.

I know that doesn't solve your problem, but just thought I'd mention it for ideas. 

Also, a common LM317 is easy to make it output 1.8v from from the 5v input, as another option. 2 capacitors and 2 resistors. It's hard to even burn them out, they shut themselves down with overcurrent.


 

Aciera wrote:

I think you might be missing this in your hal file:

net tool-change iocontrol.0.tool-change iocontrol.0.tool-changed

[edit]

for troubleshooting it might also make sense to use the 'show halconfiguration' to watch the iocontrol.* pins like
iocontrol.0.tool-prepare
iocontrol.0.tool-prepared
iocontrol.0.tool-change

[edit2]

Just so we are on the same page, I presume you have tried the suggested (ie reversed M6 T..):

[code]T.. M6

[/code]

Reversing to Tn M6 did not help.
Adding also did not do the trick but then I tried the second part of your suggestion of watching those iocontrol pins that relate to tool change and noticed that tool-prepare goes high that led me to think that it might be waiting for the tool to become prepared, so I tried thisand ended up with MSG messages displayed and some actual motion to happen. Thank you very much!!! That was a silly mistake as usual!

I will need to play with the scale some (and look into the choke you mentioned), but it now works. I was replacing "net spindle-output <= pid.s.output" with "net spindle-output => hm2_7i97.0.pwmgen.04.value", when I needed both present in the hal file. Another bonehead move...

Thank you for helping me.

Thank you for quick reply.

Since 7i76e are not available, I am planning to buy 7i96S instead. Are they a suitable replacement for 7i76e? My setup is very basic, file is attached. Mesa cards just confuse me...

Those errors suggest a problem with either the 7I76E field I/O side power supply or
serial communications (not a specific issue of the inputs)

If you contact Mesa by email, they can issue a RMA for analysis/repair/replacement
of the card.

This is absolutely infuriating!

all the axis move when homing, homing is successfull, but afterwards only one of the Ys moves.
And I've red the post "homing configuration" several times, there is literally nothing about configuring two axis as a gantry. There only is something about when you have a gantry setup, that somethings should be taken care of.
The last line, which says to look at the exampleconfig a gantry machine, was also only semi helpful since 1. This example config wasn't even available on my variant of linuxcnc, and 2. Since there is nothing helpful in the example config, 

Any help is still much appreciated. Any ideas, I'll take them all and try.

I am running 7i76e with linuxcnc 2.8.4 for a engraving router for a year now and today it started to give a fault while machining(file attached). After 5 minutes it stopped working entirely and gave me a warning at the start saying input-08 is not plugged in. I removed the number 8 from Pncconf and tried again but then it was input-09. I removed all of them it was the spindle, after the spindle machine turned on. XYZ axis work no problem but nothing else. I then swapped the 7i76e from a different machine that I have and problem was solved. Is my card dead or is there something that I can do?

If you don't set the PWM value, the output voltage will not change.
you need:net spindle-output hm2_7i97.0.pwmgen.04.value

The 460 RPM when connected at ~0V is probably a noise issue
This may be soluble with a common mode choke on the spindle 4
analog output and ground.

I have setup the enable pin in my io.hal and classic ladder files. I am able to rotate the spindle in either direction at about 460 rpm with the buttons on gmmocapy.

Sadly I have no control over the speed. It is either on or off. The multi-meter reads at 0.009v when at 460 rpm. If the 0-10v wires are disconnected from the spindle drive the speed is 6 rpm in either selected direction.

I found someone else's hal and ini on the forum and noticed their spindle-output was net-ed to their pwmgen.04.value. My spindle-output is net-ed to pid.s.output. I tried each method without any change in behavior.

My pwmgen.04.value is not currently connected to anything. Should it be? (Reading the pwmgen section of the docs makes me think this is my problem.)

I have attached updated hal and ini files. 

stickys wrote:

Hey guys!
Successfully installed firmware, now it's moving
Do you have a full config .file, for spindle, inputs, outputs etc. for sample?
Tried to add homing switches, I wrote remora.input.03 but it said unkown pin.
I have dual Y axis, I followed the tutorials but only one motor is moving, if I set sync home sequence it will be OK?

Great to hear. There are example configs in the following link. Check out the hypercube hal and ini files. This shows how to setup dual axes. Dual Z in this case but the same is for dual Y. For a dual axis setup, don't jog in manual until after you have homed the axes, they will not jog together until homed.

Remora/LinuxCNC/ConfigSamples at main · scottalford75/Remora