Yes, unless somebody have better terms, I prefer to call the USB part the dongle and the actual handheld device the pendant. In case of the wired version, I would presume all logic is in the pendant and the "USB part" is only a connector.

The problem for everybody else than myself is that you might have different hardware/firmware version. And if you overwrite the factory firmware with this new firmware, you can no longer go back, because you don't have the factory firmware. I could give you the factory firmware that was in my dongle, but it could be different than what is in yours. The firmware can be extracted (like I have done), but its tedious.

Anyway, I think its a little bit early for public beta testing. I will make some improvements and see if it appears stable over time. Maybe there could be some way to do at least a partial readout/verification of the factory firmware through USB.

Checked. It was about relays and laser, nothing about rotation of the motor with preset speed, like M3 S1000.

Dongle is the thing we put in the usb port, right? 
What do I need to test?

You are miles ahead with knowledge about this device. I'll help were I can, like testing.

Here is the dongle firmware I am developing:
github.com/finngineering/whb04b

I would say it is mostly working. However, there are some things I would still like to improve. And for sure it needs some more long-term testing. But I do think this has the potential to be better than the factory firmware in almost every way.

I'm making some progress with pktuart approach. I updated my lathe firmware with 7i96_pktv3d.bit and I can see the pkuart pin assignments on the 7i96.

I simplified my config (7i85S encoders aren't available with this firmware) and I can get my config to load. Later today I will make a connector and try it out.

I did experienced a problem with TWOPASS. When I enable TWOPASS in the GS10 example, the parameters to loadrt hm2_eth and hm2_modbus get messed up???

This problem can be duplicated by adding TWOPASS to the .ini inside gs10.zip from forum.linuxcnc.org/10-advanced-configura...20File%20Size:5%20KB .

Enabling TWOPASS with the ini variables fails if TWOPASS is enabled. If I don't use the substituion, the hm_gs10 example config loads with TWOPASS.

AlessandroEmm wrote:

• Code:

  [b]Configuration is default remora:[/b]
• Code:

  [b][code]net user-enable-out <= iocontrol.0.user-enable-out => remora.SPI-enable
  [/code][/b]
• Code:

  [b][code]net user-request-enable <= iocontrol.0.user-request-enable => remora.SPI-reset
  [/code][/b]
• Code:

  [b][code]net remora-status <= remora.SPI-status => iocontrol.0.emc-enable-in
  [/code][/b]

I did it a long time ago and unfortunately I don't remember...
But I think I had the same problem.
My configuration looks like this: This is Remora via Ethernet, but the differences are probably cosmetic.

They were actually 10cm, now they are closer to 4. Unfortunately wasnt the (root) cause of my issues.

Es hat super funktioniert bzw bei sserialport1 hat der die ganze zeit beim start einen fehler geschmissen also hab ich sserial 0 auf 222222222 gesetzt und es geht ,ich bekomme die Vorschub und Spindel override slider nicht mit den analogwerten verbunden ich kann in der hal sehen dass sich die Werte ändernbekomme das aber nicht so hin , dass dann auch die slider angestesteuert werden also da ändert sich nichts bei dem Wert der overrides , eventuell kann da ja wer mal ein Beispiel hal Teil schreiben welcher mir dort weiterhilft , gruß Tom

Thanks PCW! I replace the diode and board works again

Hi,

I think you have a syntax error.
setp iocontrol.0.emc-enable-in 1

MikkelRS wrote:

Pretty awesome machine! And you're local to me.( I see your base machine on Kijiji


 

Ha, nice. thanks.

I flashed back the factory firmware to the dongle for some tests. With no program polling the pendant, pushing buttons and rotating knobs makes the dongle disconnect faster than if left alone. Somewhat surprisingly, turning the jog wheel makes the dongle reconnect faster than if left alone. So if you continuously spin the wheel, the disconnect/reconnect cycle will be much faster. I have not tried to check why, nor do I think it matters much in the end.

Also my pendant shows the F: and S: properly, so maybe it's something with the wired version. For debugging, I think the second best to a hardware USB analyser is Wireshark. It's pretty easy to monitor the USB requests/replies, and I can help with "setup" if needed. URB_INTERRUPT in is the data from the pendant and SET_REPORT is the data to the pendant (split up into 3 parts).

Yes, the STM32G030C8T6 could be replaced. Or reprogrammed in place, because that is not protected. But without the factory firmware, it's more difficult to figure out how to drive the display and the RF module. Although now that I have the dongle firmware somewhat working, the RF part for the pendant is probably pretty much the same.

The dongle mostly translates between USB on one side and 433MHz RF on the other. The microcontroller (at least in my dongle) is a CH554 and the RF module is a HW3000.

@Waggi : Noch einmal Danke für deine Antwort.

Bis es soweit ist, dass ich eine Spindel an meine Maschine schraube, vergeht sicherlich noch einige Zeit.Optimistisch gesehen Ende des Jahres.
Um einzuschätzen, was die Mechanik dann letztendlich kann, fehlt mir die Erfahrung. Alles in allem denke ich aber, da geht schon was.

Ja, der Bau macht Spaß, aber wenn es sich vermeiden lässt, belasse ich das "Lehrgeld" lieber im Material-Budget.

Für mich kommt eine Werkzeugaufnahme per Druckluft nicht in die Auswahl. Es scheint ja so, dass es nicht nur einfach einen Kompressor braucht.

Setup:

• LinuxCNC with Remora SPI controller
• 4-axis gantry configuration (XYYZ - dual Y motors)

My System is stuck in E-STOP state and cannot be cleared with F1 or any other method in Axis. F2 (Machine On) is greyed out all the time. The HAL states look fine from Remora side, thus i'm pretty certain that my issue is with some state/config that is LinuxCNC core. I tried other Frontends like gmoccapy and they behave pretty much the same except that they seem to have some timeout on e-stop blockage and claims that something external is blocking it while axis is keeping at it and never times out, but nothing ever changes even after minutes.

I have endstops configured too, but still tried no_force_homing to ensure its not a problem with endstops.

Some Infos about my setup:HAL Pin States: HAL Configuration is default remora:
INI Configuration:  What is interesting is that noticed on click of e-stop the previously greyed out box of override limits becomes clickable.

Thanks for any help,
Alessandro