Advanced Search

Hi
Has anyone had experience with this controller? I plan to do a retrofit, but these drivers are not very clear to me, i.e. I'm not sure if they have an analog input somewhere? Thanks

I acknowledged most of that.  It’s ok to just say “Thank You”.

Qtdragon_hd normal open 100-120Mb file. It takes about 40 sec on N100 with 8gb ram and ssd disk.

That is correct. 9 stepgens (6 for the main hardware + 3 for the BoB).

 

The inputs and outputs on TB3 are described on Page 10 of the document you shared

I think you never expected somebody to upgrade a sim. Normally you would just reinstall it but in this case, but there was a reason.
The biggest issue, is that there is a total lack of error logging and even the error window does not report that it is a QTplasmac message. eg. It could have belonged to the Linuxcnc core, qtvcp or qtplasmac. I had no idea. 

I think its worth fixing sooner than later becasue once Andy has sorted out his 64 bit integers, he will release 2.10 and then there will be crowds of people upgrading from 2.9.x to 2.10, so more chance of problems.

Attached is the clients full config. 
As I thought, runstep.hal is not loaded in the .INI file (ie commented out) so keep looking!

It is appreciated. 

vibram wrote:

How is it possible to monitor pwm sign in order to answer your question?
 

Watch the pwm value: hm2_7i96s.0.pwmgen.00.value

Did you try open loop operation to see if that's OK?
(open loop means P,I,D = 0, FF0=1)
 You should definitely get that working first.

I'm undergoing a similar lathe project using a pi5 and beckhoff modules however I'll be using the drive itself for the fully closed loop. I'd suggest looking at leadshine's EL8 drives. They allow a dual encoder input so you'll have your typical rotary encoder mounted on your servo, as well as a linear scale (in my case magnetic) connected to the second input. I'm also splitting the linear scale input to a beckhoff module. I hope this might help.

rodw wrote:

Just accept that I ran a Sim in Step 2 and it copied it to the configs folder
You tests prove nothing becasue you have not taken a sim installed under 2.94 then run it under to 2.10 (steps 5,6,7)
You are clearly not listening to the issue or following my instructions to replicate the issue. Tommy just goes off on a tangent on Item 2.

It seems neither Tommy nor I fully understood what you were doing in step 2. I follow now.

While waiting for clarification, I was attempting to replicate your issue and validate the process.

What I wanted to do is simply confirm using a SIM, things would work once I asked a customer to upgrade a live install on a production table over 1000 miles from me. Doing it on the sim found some issues. They may not apply to a live install.

Honestly, it seems like you’d benefit from learning how to simulate your customer’s actual machine. This guide explains how to convert a “live” config into a simulation config, which you may find more useful than the bog standard simulation config: forum.linuxcnc.org/plasmac/43425-simulator-for-qtplasmac

I am done with this issue as I received enough information to solve the problem manually from Snowgoer's initial post.

It’s good you were able to gather enough information to solve the problem manually.

The core issue stems from the interaction between the .ini file and the .inc file, resulting in ini.combined. The changes were correctly applied to that file, but the problem is that it’s overwritten every time LinuxCNC launches, so it applies the changes repeatedly.

I still maintain that this is an issue related to your setup/installation and/or an unintended use case. That said, I’m considering adding a check for “expanded” in the filename and display a warning if it looks like an older simulation config is being used. I’m also considering tweaking some of the messaging to clarify this process moving forward.

Thanks for being patient with me while I worked through this.

try this:

setp   hm2_5i25.0.pwmgen.pwm_frequency 1000
setp   hm2_5i25.0.pwmgen.00.scale 100
net pwm-enable <= motion.motion-enabled  => hm2_5i25.0.pwmgen.00.enable
net pwm-output hm2_5i25.0.pwmgen.00.value

This assumes pwm-output is a signal that has the current desired PWM value


And delete this line:

loadrt pwmgen output_type=0

Note: if you have a issue with names, you can list all pwm related pin/parameter names with

halcmd show all | grep pwm

(when LinuxCNC is running)

On bare FPGA pins (like on P1) any pin can be an input or output
_IF_ if it's  secondary function is disabled (or it has no secondary function)
Secondary functions can be disabled in the hal file with the num_xxxx=N stanzas

For example, the default 7I96S firmware has just GPIO (no secondary function)
on P1 so all P1 pins can be input or output. On a more complex configuration
say 7i96s_5abobd, the P1 pins used for the second encoder inputs can only be
inputs unless you disable the second encoder in the hal file (num_encoders=1)
(this leaves the encoder on the 7I96S card itself enabled)


The hostmot2  manual page has more details


 

scotth wrote:

The only problem I'm having is the Software Manager hangs up and says "Loading please wait".

In a terminal
sudo apt install flatpak
That is the reason software manager does not start and i mentioned that i removed it as i never use it, i use terminal exclusively.

Thanks again!

That last suggesting, to use hal to monitor it...

I'm familiar with setting up the game-pad pendant, and so my recollection is that you add some mux-es and ands and ors to the servo thread, and check for buttons and do the bit-math until you come up with a speed to feed into the jogging speed.

So my first thought is kinda redux that thinking: use the ands and ors and current position pins and create a section in the .ini file for limits which the ands and ors are comparing, and have the logic come up with a on/off value which gets net-ed into the Estop pin.

I think it would either have to
A: anticipate the movement somehow, (because if it used the current position, once you tripped it, you'd have no way to un-trip it. {evil grin}) and I'm clueless on how that would work,
or,
B: it would need some 'override' button, say on the jogging device, to ignore the limits and allow moving it anyway. (That's easy to imagine how it works with a final or statement.)

So the second option seems easier.

With second option, I'm thinking the e-stop button on the GUI would just trip on, everything would stop (you are spanked). Then you'd have use your pendant with override pressed to move somewhere where the e-stop button on the GUI trips back off. Then figure out how to avoid that spanking.

Is there another/better approach that comes to mind?

(I'm probably not counting the risk high enough to actually make it to the proactive action of doing this now... when I crash something badly, then I'll probably do it. Sigh. Sometimes it sucks knowing one's own psychology.)

Pretty sure 2.9.3 should be OK (7I76EU support was added 2 years ago)

Mesaflash >3.5.2