Advanced Search

@ZZ912
Implementing the Hal signal for the execute button ist possible like you described. But if you want to forbit the Keyboard Enter Key to submit the MDI command, you need to modify also the MDI History widget to ignore the enter signal. If you do that, I am sure many users will ask you to implement the old behavior again. As it concerns to me, I use the Enter key to submit the MDI commands.

The only possibility I see, is to leave the default as it is and implement a setting parameter to change that behavior.
I am not sure, but if I remeber well, the Heidenhain control does allow the execution of entered commands with the Enter key.

Norbert

I will not be in the shop today, i will provide pictures of the wiering tomorrow.

Fyi to clear this up I was able to fix it. It likely wasn't a remora-based issue

please refer to.
forum.linuxcnc.org/49-basic-configuratio...without-error#343443

That said I'm still on a 2024 commit with my current setup, as it seemed more resilient in regards to SPI Comms on F103, but i'm pretty sure upstream would work too.

Hey guys

I figured it out, as far as I can tell. I didnt put Remora in the title because the states/signals that trigger iocontrol from remora side were, as far as I was able to tell working correctly.
That said all it took was to make it explicit that my linuxcnc instance that it should run with iocontrol v2, which I did by adding

to the EMCIO section. From reading the docs I had assumed that in newer versions of LinuxCNC that it would be the default anyway, hence i never bothered. Also I never had errors.

Now to close this, whats the default today for a standard version of iocontrol in a deb-install of linux-cnc?

Thanks,
Alessandro 

qtDragon: Automatically Return to Manual Mode After an MDI CommandThe ProblemIf you use a pendant with qtDragon, you've probably run into this annoyance: after executing an MDI command, LinuxCNC stays in MDI mode. Before your pendant will respond to jog inputs, you have to manually click a movement button (or otherwise trigger a mode switch) to get back into manual mode. On a busy machine this gets old fast.  I use a VistaCNC P4-S.The FixThe solution is a small addition to your. We connect to LinuxCNC'sSTATUS signal, which fires whenever the interpreter finishes executing. When that signal fires and we're still in MDI mode, we automatically switch back to manual.Step 1 — Get a local copy of the handlerIf you don't already have ain your config directory, copy the system default there. LinuxCNC will automatically prefer the local copy over the system one.Step 2 — Edit the handlerOpen your localand make two small changes:In the method, add the signal connection:Add the callback method somewhere in the class:That's it.How It Works

• interp-idle

  fires whenever the interpreter becomes idle — MDI command finished, program finished, etc.
• The

  STATUS.is_mdi_mode()

  guard ensures we only switch to manual when we're actually in MDI mode, so it won't interfere with the end of a normal G-code program run.

• ACTION.SET_MANUAL_MODE()

  does exactly what it says — same as clicking the Manual button in the UI.

Notes

• Tested on LinuxCNC 2.9.6 with qtDragon.
• This should work on any 2.9.x build without modification.
• If you're on 2.8, the same approach should work but

  STATUS

  and

  ACTION

  import paths may differ slightly depending on your build.
• This does not affect program (auto) mode — when a G-code program finishes it will stay in auto mode as expected, since

  is_mdi_mode()

  will return False.

CreditFigured this out with a little help. Posting here so the next person doesn't spend 3 hours on it.Hope this helps someone!

It's supposed to be a 7i85 not a 7i85s. I'll have to check it in the morning.
I'll also have to check the piece of patch cable I used. It's possible the cable could be suspect.

And so IMHO it does not really make sense to have a hardware button to send MDI commands which you need to type with the keyboard.

It makes sense. But the reason is not the one described by BertaA.

My dream is to build a CNC machine, controlled by LinuxCNC, that will meet all the requirements (standards and laws) for a CNC machine that the European Union requires. I think that it is possible to compete with brands like Heidenhain, Siemens, Fanuc ... in a certain category of machines.

When I studied the safety standards for CNC machines, I found a requirement there:
MDI commands or sequence commands must be executable only with a physical button. I think that the standard even described what the button should look like. I don't remember exactly because it's been a long time since I read it.

Therefore, it would not be bad to make a configuration that would ensure the execution of MDI commands only with a HAL signal.

Yes, it may be a cable issue.

Just verified that:

7i76eu_7i76x1_7i85x1d.bin from the distribution zip file.

md5 checksum:

485114d3d22390a7e5b44d77588981c5  7i76eu_7i76x1_7i85x1d.bin

Works correctly with a 7I85 on P1 (all 5 sserial ports on the 7I85 work correctly)

Is it possible you have a 7I85S rather than 7I85?





 

Yes, it was sleeping for days before it received the kiss of life!

rodw wrote:

I drew up my own pin out diagram converting the wire colours to be correct and my 7i73 woke up!

Did it sleep well ?

Take care here, Network cabling comes in two different flavours T568B and T568A. Google for the difference
In my case, Mesa's serial port manual describes one of these standards but in my country the normal standard was the other!
I drew up my own pin out diagram converting the wire colours to be correct and my 7i73 woke up!

Changed the subject tittle to reflect use of Remora, is that OK?

Pictures of the wiring?

I'll try and get to the 7I96 configuration later today or tomorrow

but note you need a  RS-485 interface, and that's only available on the 7I96 configuration.
The 7I92 configs  would need to add a RS-485 chip or a daughtercard with a RS-485 interface.


 

I added the RS485 termination resistors and I'm successfully talking to the VFD.

When I get new firmware I will retry automatic gear detection with a faster update of the motor frequency.