Hitachi X200 VFD

I need to be able to control my Hitachi X200 VFD through Modbus (RS485). I was successful at this under Mach3 at least.

I believe it's the same interface as the Hitachi WJ200, but I'm not sure.

I haven't found code posted yet, but surely people have done this? I did see where people had done the cheapo Huangyang VFDs and the best plan I could come up with so far is recode that for the X200.

Any better ideas? Is there X200 Modbus code kept in a closet somewhere?

the hitachi wj200 is part of linuxcnc , and is already included

linuxcnc.org/docs/html/man/man9/wj200_vfd.9.html

Yeah I'm sorry but I'm baffled what that man page means and what I need to do here. There's a serial port with an RS485 adapter so it needs to be bound to the port. So this converts Modbus communication and makes it appear as HAL pins? But the pins still need to be tied into LinuxCNC's operation manually?

Update: I was able to recompile the WJ200 code to work with my X200.

The coils are just slightly different numberings. Why... why so close yet not the same.

The DIR read-value is reversed on the X200... weirdly the complement of the value you write to it.

WJ200 has a bug in it. The RPM is 10x larger than you provide, for either X200 or WJ200.

Hi Danny

Would you mind sharing what you did? I am currently using MB2HAL to drive my X200 but tried to get the WJ200 file to work without luck.

Cheers

.comp file enclosed. There's some stdout messaging I was using for diagnostics that need to be removed.

I am a bit disappointed in the integration of the WJ200 code, but haven't done anything to improve it. That is, if the VFD fails to start or overcurrents, it'll just try to put it into Run mode again in a continuous loop. That's not very robust. An overcurrent should be a e-stop or at least a Feed Hold.

andypugh wrote:

dannym wrote:

That is, if the VFD fails to start or overcurrents, it'll just try to put it into Run mode again in a continuous loop.

Does such an event set "is-alarm" pin? If so I would imagine that the intention would be that that pin would be linked to an appropriate HAL pin (either feed-hold, or maybe even motion.enable for a more extreme reaction.

You know, maybe. It was a few weeks ago that I worked on that. Once you figure out how to compile and include it, it's no big deal to add more functionality.