Greetings Sara and Colleagues,

I am writing a PV380 configuration that will implement IX3212 control.

I have configured the following "Control Message" for the IX3212 within the CAN Transmit functionality of the PV380.
I wanted to confirm that I was on the right track before I spend too long staring at CAN traces trying to work out if things are the correct "endian".

I appreciate any assistance you can provide.
Obviously if you have any example configurations involving the PV380 and an IX3212, I would be most interested!

Kind Regards,
Alex

I have just realised that the manner in which the IX3212 communicates via CAN (namely using 1 PGN with a differentiating Identifier) means that the standard freeform CAN functionality will likely not suffice... Do you have any suggestions for how to parse these messages within PowerVision?

An update:
I determined that I can use filters in the freeform CAN message section in order to filter by the Identifier in each message, I've been able to successfully test this by reading in the digital input feedback message.

Hello Hamsteh,

Thank you for the additional information. I have every confidence that you will find a usable way to communicate between a PV380 and the IX3212. We would certainly appreciate any knowledge you can share here in order to help others who may have similar projects!

I'm here to help if possible.

Hi Sara,

Is it acceptable to send configuration messages to the IX3212 in very quick succession? (ie. In a single Activity Program?)
CANCapture is showing all 14 messages being sent, but they ARE very close together (0.58ms according to CANCapture)

Do I need to manually add delays between each message?

Thanks in advance,
Alex

It would appear that the IX3212 is unable to interpret configuration messages delivered so closely together.
Adding a delay between them appears to cause the config to be correctly modified.

Hi!

In the literature for the Configure Output message 4.3.1, shows On Change, so seems like you could send them as frequent as you need, it just might take some time for the PDM to process. Is the PDM sending back the response, to all of the messages you sent?

Can you tell I don't really know what is going on? ;-)

Hi Sarah,

I'm not sure exactly, I'll have to have another play with it when I get the chance but for the moment by staggering the config messages I am able to 'somewhat' successfully write the channel configs.

I am having this problem at the moment, however:

I am sending the following packet in order to configure channel 1: As you can see in the 5th byte (03) this is setting Loss of Communication to 11b which should correspond to 0% on loss of communication.

For some reason it appears to be acting as if set for "00 = CH Unchanged (Last Commanded)", and upon inspection of the corresponding Output Function Handshake packet I have noticed that this byte is returning FF instead of 03. Is this expected? Is the IX3212 padding the remains of the byte with 1's? Or is it failing to correctly configure the Loss of Comm setting?

EDIT: Or alternatively, have I structured these messages incorrectly?

Thanks in advance!

Hi Alex,

I don't have anything very useful for you today, but from what I can tell, you should be getting back in the response message, the same values you send to the PDM unless something is wrong.

Somebody suggested if you have a color display available, you could use one of the example configs found here on the forum for a PV780 and capture the traffic from the color display to get some reliable information you can use for the free form messages from the PV380.

For the Loss of Communication byte issue, I'm not sure if the H_Bridge setting would affect the PDM's response or not, the documentation doesn't indicate that it should, but you might test a little to see if that setting makes a difference in the response.

I'm trying to find better details to help you with your questions.

Hi Sara,

The PV450 I had organised to borrow showed up the other day and I was able to observe the IX3212 control messages. It would appear that the standard configuration actually pads out the configuration messages with 1's - something that I don't believe is outlined in the documentation.

It turns out that my Loss of Comm settings were actually the same as those in the PV450, but my POR Command was set to 0 as opposed to 255 in the PV450. Setting my POR Command to 255 and POR Enable to 1 has made Loss of Comm function correctly... bit weird but for the moment it works. The documentation instructs a POR Command of 0, but this did not seem to function correctly.

I think the IX3212 documentation needs a little work!

Thanks for all your assistance thus far.

Can I please confirm what functionality results from a current limit of 0.0A?

Hello Hamsteh,

The functionality is to do nothing, no output with the default 0.0A. You should have to set the current limit to something other than 0.

The values should be configured in 2.5 amp steps.

Thanks Sara, I have been using 15.0A just wanted to better understand the function of the 0.0A limit.

Hi Sara,

I am having difficulties driving the H-Bridge output.
It will function correctly in the +100% direction, but gives me 0V when I command -100%

I have a CAN Capture of the Command Output Message I'm sending, with the packet as follows (on output 5):
4 127 127 127 127 127 0 145 (+100%)
4 127 127 127 127 128 0 145 (-100%)

I have configured the output with the following configuration messages:
0 5 102 1 255 255 252 255
6 108 108 108 108 109 255 255

Are you able to confirm whether I am correctly providing the message required to drive a H-Bridge output at -100%?

Thank you kindly in advance.

Hi Hamsteh,

I believe the problem you're having with driving the output to -100% in H-Bridge mode is related to the Enable bit for channel 6. In your example, the last byte is 145 / 0x91 / 0b10010001. This means that the Enable bit for channel 5 is 1, but the Enable bit for channel 6 is 0. Have you tried setting the Enable bit to 1 for channel 6 by setting the last byte of your command message to 177 / 0xB1 / 0b10110001 ?

Other than that your message looks correct to me. When in H-Bridge mode, the commands go to the odd channel, in this case channel 5.

As to your previous posts, I believe there is an error in the documentation. The POR Enable bit is 1 for disabled, and 0 for enabled. This seems backwards as far as Boolean logic goes, but the default state for all PDM values is 1 (or idle-high), and POR defaults to off, leading to 1 = disabled. I will let the documentation group know to update this error. Otherwise the documentation for the POR Command values are correct.

As far as Loss of Comm goes, there are only two bits to set, with the remaining 6 bits left at the default state of 1. So the following values should be used for the 5th byte of the output configuration message:

• 255 / 0xFF = Disabled / Off / 0% (Loss of Comm bits = 0b11)
• 254 / 0xFE = +100% (Loss of Comm bits = 0b10)
• 253 / 0xFD = -100% (H-Bridge only; Loss of Comm bits = 0b01)
• 252 / 0xFC = Unchanged / Last Commanded (Loss of Comm bits = 0b00)

Let me know if this helps or if you have more questions.

Thanks

Hi Joe,

Firstly thank you for the detailed response.

You are correct that the issue was the enable bit for output 6, we actually determined this yesterday using a CANCapture from a PV450 running the IX3212 application. I could be mistaken but I do not recall being instructed to enable the second channel for use as a H-Bridge, I presumed it would be 0 as instructed with the second channel's Command bits.

The fact that there was a documentation error with regards to POR Enable makes sense, and I would suggest that the Loss of Comms description includes instructions to pad those extra bits with 1's - as this is not immediately apparent from the reference documentation. This too was learnt using a CANCapture from the IX3212 application.

We appear to be at a working state now, thank you again for your help.

Hi Hamsteh,

The output enable bits kind of act as a master kill switch for the outputs, so having the enable bit set to 0 will preclude the output from performing any operation and takes precedence over all else. This can be annoying when you're debugging an issue, like you encountered, but it is handy when you need a failsafe or safety mode - it makes shutting down all of the outputs very easy.

I agree that the documentation should indicate filling the unused bits with 1s. The main problem is that the message definition indicates the Loss of Comm field as a full byte, when it's actually only 2 bits. Any unused/reserved bits in the communication will always be 1. This is the default state, and is useful for backwards compatibility. That's why we have the strange case of 0 = enabled and 1 = disabled for POR, because that was a new feature, so the default/reserved case is 1. That way any old head units that aren't aware of the new feature won't be enabling POR by accident.

Glad to hear you have everything up and running now! I have submitted the corrections to our documentation group so hopefully the updated manual will be on the site soon.

Thanks