This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MCF8316AEVM: GUI restart and controls problem

Part Number: MCF8316AEVM
Other Parts Discussed in Thread: MCF8316A

Hi All,

1. I downloaded the offline version of the GUI v1.1.8 and it behaves strange: It starts OK for the first time, works OK as well, however when I need to restart it, it shows logo only and then does not show the main window at all until I restart my PC. What can cause such a behavior?

2. The reason I restart the GUI each time is that once I have overcurrent fault (after I clear it), I cannot start the motor at all (speed controls do not work), only power cycling helps, but then I get a pop-up message "restart the GUI". What can I do in order not to make all these restarts?

  • Little update to problem #1:

    During GUI restart few instances of \guicomposer\runtime\gcruntime.v11\runtime\node-webkit\nw.exe remain running.

    So, once I manually killed them in task manager, I was able to run the GUI again without restarting my PC.

  • Hi Boris, 

    Thanks for posting your question to the e2e forum - 

    I've assigned this thread to a team member, and we'll aim to provide a response next week 

    Best Regards, 
    Andrew

  • Hi Boris,

    Regarding the issue where the GUI disconnects and you're unable to start the motor after fault, could you please make sure to refrain from reading/writing to the device via I2C and disable the "Auto Read" buttons in the GUI while spinning the motor? There is an errata on the MCF8316A that causes the device algorithm to become stuck if when I2C commands are sent constantly during motor operation. This errata will be fixed in the next device revision.

    Regards,
    Eric C.

  • Thanks a lot, Eric and Andrew!

    I have some other questions; may I continue asking in this thread or should I open a new one? 

    Best Regards,

    Boris.

  • Hi Boris, 

    Appreciated on helping confirm the answer!

    E2E best-practices would suggest that if your new questions are similar/related to the one you asked in this thread, then we can keep the follow-up questions in the same thread so that we have proper context and don't need to spend as much time connecting info from multiple threads.

    If the new questions are very different topics or information, we can separate that into a new thread and even link back to this one if needed. Note the 'Ask a related question' button within the e2e menu (upper right corner?) 

    Best Regards, 
    Andrew 

  • Hi Andrew,

    Thank You for clarification,

    My first 2 questions are relevant to the context of the thread, so:

    1. Eric mentioned that "There is an errata on the MCF8316A..." Is there any document describing it? Could You please share a link?

    2. Can I still use occasional I2C commands for speed and braking control without a risk to make the control loop stuck, or I'm strictly limited to pin-defined controls?

    Thanks a lot and Best Regards,

    Boris.

  • Hi Boris,

    1. Eric mentioned that "There is an errata on the MCF8316A..." Is there any document describing it? Could You please share a link?
      The MCF8316A errata are listed in this E2E FAQ.
    2. Can I still use occasional I2C commands for speed and braking control without a risk to make the control loop stuck, or I'm strictly limited to pin-defined controls?
      Unfortunately, due to this errata, whenever the device is under motor operation, any I2C command can have the potential of triggering the issue, so I'd recommend using direct PIN controls for speed and brake control during motor operation on the A revision device.

    Regards,
    Eric C.