Advanced Search

the only other clue i can offer up at this point would be the fact that the bearing was not pressed in the motor housing. it came right out so maybe a poor press fit added to this?

Ooops, you need  a link github.com/dbraun1981/hal-cia402

Hi @all,

i'm using LinuxCNC 2.9.3 in combination with a Mesa 7i96s to control my JMC servo based x-y-z laser handling system.
I added the following components to my system:
- gladevcp
- WHB HB04
- Arduinoconnector (for periphery like compressed air, lamps, fume extraction...)
and thanks to your posts and the detailed videos of talla83 and alexmagtoast i somehow got it working. Thank you very, very much.
I'm based in mechanical engineering so the software and electronics part is fun but a steep learning curve. This is my first self-build maschine.

My current problem:
I have a second PC with a third party software for setting the laser parameters. For adjusting the focus, this pc can put out 5V step/dir TTL signals 5 μs for steppers. In the machine setup process i would like to use this signals to control my z- and x-axis.
I cant just connect it to the steppers because it would corrupt the position in LinuxCNC, so my idea was to connect this TTL signal to the encoder input of the mesa.

Wiring:
Jumper W1 in left position (for single ended TTL encoders)
step+ on ENCA+ (TB2-7)
step-gnd on GND (TB2-9)
dir+ on GPIO38 (successfully shows in HALshow)
dir- on GPIO GND

Would that work in principle? Can i just use a GPIO pin instead?
Do i need to configure the encoder somehow?
While writing this i realised my logical mistake might be that a single ended encoder still uses ENCA+ for positive and ENCB+ for negative direction?

In my custom_postgui.hal i use the following code but it doesnt register anything in halshow.



Help would be very appreciated.

Best regards,
Chris

zarfld wrote:

an minor issue which i can workaraound by just providing pos_fb=0.0 during homing procedure on pokeys is that i don't know how to "Pause" Linuxcnc from checkeing pos_fb versus pos_cmd for following errors during homing procedure.

You use a component that sets pos_cmd == pos_fb while homing.
An example of this is the cia402.comp used with Ethercat drives.

@Rodw,

Thank you for your effort, all your input so far.

I have tried to create a .iso for day's, using the lb build system and also by using a chroot environment.
However it failed at some point when the .iso installation was ~60% complete.
Also the linuxcnc live build failed at some point, it had something todo with filmware, but that's no problem.

Then creating .deb packages is also a lot off work. As you have at least 2 types. The normal packages and the -dev packages
wich includes .headers etc.
I think we have to use 3 types, like the normal, the -dev and the -source.

For now i use a Qemu vm. Install debian and the software we need. Then the Qemu .img file can be compressed and
downloaded by others to test in their vm.
For running on real machines, i have to do a extra conversion step from .img to other .img type,
then write the .img to usb, and it will run.

thanks for the answer!

the "errors" seem to be the limitswitches. (i need to check the simulation).i disconnected the HAL signals from joints and now that works.

an minor issue which i can workaraound by just providing pos_fb=0.0 during homing procedure on pokeys is that i don't know how to "Pause" Linuxcnc from checkeing pos_fb versus pos_cmd for following errors during homing procedure.
(in homing.c i have seen some "free_tp.enable=0" and applying ofstes to pos_fb and pos_cmd - i think i have to check that more in detail)

BR
Dominik 

Hi Giovanni,
Thank you very much for your efforts in integrating the NativeCAM plugin into the current version of LinuxCNC 2.9.4. Thanks to everyone else as well.
I've been looking for a way to generate simple programs within the LinuxCNC control system for a while. I only came across the NativeCAM plugin late. I installed NativeCAM according to the instructions and have now got it running as a plugin in the axis environment.

However, I have the problem that I can access the NativeCAM preferences, but the settings aren't saved. Can anyone else confirm this?

I also can't run NativeCAM as a standalone program with the command: "ncam -i (path to ini file) -c mill." This results in error messages. I'll add them later.
I would like to run NativeCAM alongside the QTDragon screen (as a standalone program) if possible. Would that be possible?

Thank you very much, and I ask for your help.
(translated from German to English via Google translate)

just run the override flag : I just don't understand how to use it. Thank you

pgf wrote:

I've just implemented this for myself.

I already have autoprobe routines that set g54 parameters for X, Y, and Z. I augmented my autoprobe functions to log the x and y values of every completed probe, along with the g54 offsets in effect at the time.

When I have a rotated part, I touch it twice, along a surface that's parallel to its twisted X axis. That gives me two new log entries. I have a script that level devil  reads those entries, and calculates d = atan ( (y2 - y1) / (x2 - x1) ), after correcting the x and y values with the offset information.

The script prints the result in degrees. In fact, the script simply prints the necessary g-code: "G10 L2 P0 R $angle", which I then pasted into the MDI window.
 
Once you generate the G-code command with the calculated angle, do you have any specific procedures for verifying the machine’s response after you paste it into the MDI window?

Once you generate the G-code command with the calculated angle, do you have any specific procedures for verifying the machine’s response after you paste it into the MDI window?

Fortunately this one is a reasonably easy fix:

it will spit out an error advising that you need to work inside a virtual environment, since you probably aren’t using your LinuxCNC machine for Python development, just run the override flag. Apologies I am typing on the go otherwise I’d look up the exact flag you need to add.

Where are you getting the info?
No DC side relays nor switches!!!
Never switch the DC side, unless you're in the solar panel business.

tommylight wrote:

Seems a bit excessive and not very useful.
It is much better to use a single small industrial switch and 4 of automatic fuses inside the control box, you can switch on/off automatic fuses as they can handle a bit of torture although they are not made for it, but since they will be used during testing only, they will be fine.
 

Hi,

Regarding the automatic fuses, I understand that we can also use DC circuit breakers.

I am studying to understand how to select appropriate DC circuit breakers for different PSUs and loads.

I understand that: Fuse Rating in Amp = Load Current x 1.25

I am using the Mean-Well MDR-100-24 PSU whose output is 24VDC 4A to power the 8 proximity switches exclusively.

The current rating for each of the switch is 300mA. In theory, 4 of the switches could activated at the same time, the maximum Load Current is 4 x 300mA = 1.2A.

But because the switches are just inputs to the Mesa 7I96S, I understand that, in this case, they draw very little current, maximum about 20mA each.

The maximum Load Current is then: 4 x 20mA = 80mA.

An DC-rated miniature circuit breaker is:

- Current: 1A - 2A

- Voltage: greater than or equal to 24VDC; up to 60VDC or 125VDC

- Curve Type: Type B

Is this correct, please?

Thank you and best regards,

...behai.

 

Got some goodies too. 

Got the table modified last week.

Pushed a change to Master to use 64 bit integers for hm2 quadrature
encoder count values rather than 32 bit, Seems to work as expected.
(32 bit ints cause a wrap at  a count of 2147483648)

(looped back a stepgen at 30 M counts/sec to the encoder
input to test, still took a while...)