Problem: Siemens V20 VFD not working #1452

Ask the author of #457, who submitted the V20 code. The fluidnc developers do not have one and this have no experience with it.

Yeah sure. @RootCNC can advise?

Hey Ramack, when you commanded to the turn spindle on, Did you send a speed command with it? If not. I would expect this error, as the spindle starts up to it’s minimum speed. Which could be different to the minimum speed Fluidnc is expecting.

Please try and sending a spindle command with a relative high speed. For example, “M3 S10000”

Thanks for thw tipp, I tried this, as also S10000 alone, followed by M3. Even started the spindle at th VFD in manual mode and issued the command then, but had the same:

[MSG:INFO: SiemensV20 Spindle Tx:gpio.15 Rx:gpio.16 RTS:gpio.14 Baud:9600]
ok
<Idle|MPos:0.000,0.000,0.000|FS:0,0|Ov:100,100,100>
$H
$H
[MSG:Homed:Z]
[MSG:Homed:XY]
ok
<Idle|MPos:0.000,560.000,140.000|FS:0,0>
M3 S10000
[MSG:ERR: SiemensV20 spindle did not reach device units 166. Reported value is 0]
ok
[MSG:INFO: ALARM: Spindle Control]
ALARM:10
ALARM:10

My impression is, that the VFD needs some more tweaking in the RS 485 parameters but have no idea where to start or how to debug it. Do you have a link at hand to a description of the protocol or some commands to try controlling the VFD from a Linux machine? (Rs485 USB adapter is available) – I guess there is no debug console in fluidnc available 😃

I think if you’re able to manually control the spindle with the BOP (builtin operators panel) then you might have some parameters wrong in the configuration of the VFD.

If you have a look in the V20spindle.cpp file. You’ll see a list of vfd parameters you need to set.

Thanks for pointing those out! I tried double checking them several times without any luck. – For now we have connected the 0-10V control such that we are at least able to commission our CNC. I’d still prefer to go for the RS485 connection, so I hope to find the time and motivation to dig deeper in it another day.

BTW @RootCNC isn’t the V20 also based on Modbus, so why don’t we use the generic modbus configuration for the Siemens VFD?

I derived the V20 config for the generic modbus from the code, but since I have no way to test it, I cannot be sure that it is correct. http://wiki.fluidnc.com/en/config/config_spindles#siemensv20-untested . It would be nice if someone with a V20 could test it and report the results.

I will surely test this, thanks, but need to get some issues in the orthogonality of the axis fixed first and will probably not be able to do it this weekend.

@ramack the Generic module was not a thing why at the time that module has been committed – but has been working solidly since that commit for me.

I know of a couple of users who have been using this V20 VFD type with no issues, so it is somewhat odd you’re struggling to get working.

@RootCNC does that mean that you have tested the V20 spindle with the generic module, or am I misinterpreting? Is the V20 generic config correct?

Long-term, I hope to remove as many of the hardcoded vfd spindles as possible, to save code space and complexity.

Mitch, I have not tested the Generic configuration but it looks correct. I have a feeling @ramack might need to perform a reset of the drive and ensure the registers are set as per the settings listed in the file https://github.com/bdring/FluidNC/blob/main/FluidNC/src/Spindles/VFD/SiemensV20Protocol.cpp

Yes, it certainly seems like a VFD register settings problem.

Here we go. First I was disappointed a bit, that I didn’t find any guide how to compile the code from scratch, but after seeing build-release.py installing remoteio it was easy to flash FluidNC 3.9.5-pre1 (main-18aff2e2-dirty).

So I tried configuration of the generic modbus spindle driver with:

ModbusVFD:
  debug: 3
  uart_num: 1
  modbus_id: 1
  model: SiemensV20
  cw_cmd: 06 00 63 0c 7f > echo
  ccw_cmd: 06 00 63 04 7f > echo
  off_cmd: 06 00 63 0c 7e > echo
  set_rpm_cmd: 06 00 64 rpm  > echo
#  max_rpm_cmd: 03 10 82 00 01 > 03 02 rpm*60/100
#  min_rpm_cmd: 03 10 80 00 01 > 03 02 rpm*60/100
  get_rpm_cmd: 03 00 6e 00 01 > 03 02 rpm
  speed_map: 0=0.000% 1000=0.000% 24000=100.000%
  speed_map: 0=0% 1=12.5% 3000=37.5% 9000=37.5% 24000=100%
  off_on_alarm: true

The max_rpm_cmd caused an error and it looks, like the wiki should be changed to get_max_rpm_cmd (same for min).

The log shows

[MSG:INFO: RS485 Tx:  01 03 40 21]
[MSG:INFO: RS485 Rx: ]
[MSG:INFO: RS485 No response]

while there the V20 doesn’t respond at all and I even wonder what this command is about.

So I switched back to the V20 driver and activated logging there also with

SiemensV20:
  debug: 3
  uart:
    txd_pin: gpio.15
    rxd_pin: gpio.16
    rts_pin: gpio.14
    baud: 9600
    mode: 8E1
  modbus_id: 1
  tool_num: 0
  spinup_ms: 500
  spindown_ms: 500
  speed_map: 0=0% 1=12.5% 3000=37.5% 9000=37.5% 24000=100%
  off_on_alarm: true

There I get the following:

[MSG:INFO: RS485 Tx:  01 03 00 6E 00 01 E5 D7]
[MSG:INFO: RS485 Rx:  01 03 02 00 00 B8 44]
[MSG:INFO: RS485 Tx:  01 03 00 6E 00 01 E5 D7]
[MSG:DBG: SiemensV20: setState:3 SpindleSpeed:10000]
[MSG:INFO: RS485 Rx:  01 03 02 00 00 B8 44]
[MSG:DBG: Syncing speed. Requested: 166 current:0]
[MSG:INFO: RS485 Tx:  01 03 00 6E 00 01 E5 D7]
[MSG:INFO: RS485 Rx:  01 03 02 00 00 B8 44]

So communication is working and reading the current speed (as zero) works, but adjusting the spindle speed from the UI logs state and speed changes, but doesn’t transmit anything that would make the VFD ajdust anything and after some clicks a buffer overflows.

Any ideas?

With the SiemensV20 driver from @RootCNC I get the following while running the spindle from the BOP:

[MSG:INFO: RS485 Tx:  01 03 00 6E 00 01 E5 D7]
[MSG:INFO: RS485 Rx:  01 03 02 14 9B F6 EF]
[MSG:INFO: RS485 Tx:  01 03 00 6E 00 01 E5 D7]
[MSG:INFO: RS485 Rx:  01 03 02 14 9B F6 EF]
[MSG:INFO: RS485 Tx:  01 03 00 6E 00 01 E5 D7]
[MSG:INFO: RS485 Rx:  01 03 02 14 9B F6 EF]
[MSG:INFO: RS485 Tx:  01 03 00 6E 00 01 E5 D7]
[MSG:INFO: RS485 Rx:  01 03 02 14 9B F6 EF]
[MSG:INFO: RS485 Tx:  01 03 00 6E 00 01 E5 D7]
[MSG:INFO: RS485 Rx:  01 03 02 14 9B F6 EF]
[MSG:INFO: RS485 Tx:  01 03 00 6E 00 01 E5 D7]
[MSG:INFO: RS485 Rx:  01 03 02 14 9B F6 EF]

so the speed is read correctly. Only the other commands are not transmitted…

It’s been a little while since I digested the programming manual for the V20. I seem to recall there is a register that tells the vfd what commands It can respond too. Its a mixture of speed and enable and direction commands. If you’re using CN10 (IIRC) The BOP should not respond to button pressed. So it sounds like the vfd is miss configured.

Thanks for your comment. The BOP only react when I put it explicitly in manual mode, normally it doesn’t react, and I am in CN11. As there is no command in the Tx log that would indicate any command (expect reading the current speed) I am quite sure that it’s not (only) the VFD configuration.

With the SiemensV20 spindle I at least get some communication established, with the generic ModbusVFD FluidNC only emmits too short frames (which are not in the configuration)…

SiemensV20Protocol::initialization_sequence seems to always return a handler and I get the impression that this means the initialization is never considered finished…

For the generic I have the impression that @MitchBradley injected a small issue in parsing here

Feel free to fix any errors that you find. I am busy working on the IO expander and don’t have time right now to deal with a VFD that I don’t have access to.

OMG I messed up the parity setting when configuring the generic VFD driver. We clearly need:
mode: 8E1
for the Siemens V20.

For the logs: here is an helpful document about the different modbus registers for the Siemens V20.

If you type “compile” in the wiki search box, this page comes up http://wiki.fluidnc.com/en/installation#compiling-reference-only-you-do-not-need-to-compile.

oh, yes. I didn’t search there, but only in the README.md here on github, but anyways I managed at the end by running build-release.py and fixing the error about the missing dependency.

The SiemensV20 driver is now working on my side, while I still struggled with the GenericVFD driver. – Would like to dive a bit deeper into this, as it would be cool to have only one generic driver without the need of a dedicated one, but it will take some time.

I can test again for the net release and if you prefer we can keep the ticket open until then, or you close it.

I think we can close this. In the meantime I upgraded to v3.9.6 and with the SiemensV20 driver it works. (Did not yet test with the generic driver.)

I once had an “overtemperature” warning in the V20 but the temperature calculation was not working properly due to the motor parameters, so it would be quite cool to monitor the parameters which could cause trouble and display them somewhere in FluidNC and trigger a warning before the VFD stops the spindle or even try cooling it.

But this is not essential for sure, it just happened in the early approaches and it would have been cool to see it before in FluidNC.

Also it would be cool to see live data of the power (+voltage and current?) of the spindle in a “spindle” view. Anyhow, for now I don’t even write a feature request ticket for it, maybe I will try to implement something to read more “interesting” status registers.

Considering the enormous amount of uncompensated time that we spend just trying to help people get VFDs working at all, it is unlikely that we would add extra complexity that is specific to a particular VFD, especially one that only one or two people have.

fair enough. I didn’t expect you to work on it I mainly wrote down the random thoughts I had, so far I didn’t even see a place where such details could be shown (expect maybe the console but it might not be the right place). In the long term it could be good to switch to the generic VFD driver but then such additional data readings are getting even more challenging.

So just in case you can propose some way to show additional data from the VFD (in the WebUI and FluidDial) feel free to give me a pointer.