A CODESYS download that closes the IDE almost always means the CAN rates no longer match: the controller still runs the 500 kbit/s rate your application set, while the reopened IDE starts at its 250 kbit/s default. Recover with Reset (Original), log in and download at the default, then change the IDE rate only after login and put it back before you close.
CODESYS closes the instant you attempt a download, and it does it every time you come back to the project. The cause sits in one pair of settings: the controller is still running the 500 kbit/s rate your application set, while the reopened IDE has started a session at its 250 kbit/s default. A download over that mismatched link is what ends the tool. Recover with Reset (Original), log in and download at the default, change the IDE to 500 kbit/s only after login, and put it back before you close. Below are the symptom check, the recovery order, and the arithmetic that shows the mismatch is real.
Why the IDE closes instead of logging out
A CAN link only works when both ends divide time into bits of the same length. Your application reconfigures the CAN channel to 500 kbit/s when it runs, because its traffic, one J1939 message each second in this case, is written for that rate. The controller holds that rate for as long as it stays powered.
The IDE's communication rate is a session setting. You changed it to 500 kbit/s during the last session, and everything worked: login, download, run, logout, more downloads. Closing the IDE throws that change away. The next session opens at the 250 kbit/s default and faces a controller still running 500 kbit/s.
At 250 kbit/s the IDE expects a bit to last 4 µs. The bus delivers bits that last 2 µs. No frame survives the checks, the login never completes, and here the failed download attempt closes the IDE outright instead of ending in the usual logout. That final step is what makes the case look like a broken installation. It is a settings problem with a documented recovery.
Symptoms and what each one points to
- First login after a restart fails with a communication error and logs you out; switching the IDE to 500 kbit/s fixes the rest of the session. The application controls the channel rate, and the session default is too slow for it. This part is normal for the setup.
- Login or download closes the IDE, and only after you have closed and reopened it with the controller still powered. That is the retained 500 kbit/s rate on the target against the 250 kbit/s default in the IDE. Run the recovery below.
- Everything works until the IDE closes, then the same crash returns next session. The rate you set lived only in the closed session; the default came back.
- Reset (Original) brings the login back at 250 kbit/s. The wrong rate lived on the controller, not in the cable, the interface, or the project code.
Check three things before you touch the project
- The rate the application sets the CAN channel to. Read it where the channel is configured in the project; in this fault it is 500 kbit/s for the J1939 traffic.
- The rate the current IDE session uses. After a restart it is back at the 250 kbit/s default, whatever you set last time.
- Whether the controller stayed powered across the IDE close. In this fault it did, and that is what kept the application's rate alive on the target.
Any rate you pick must sit inside what classic CAN allows, and that ceiling is 1 Mbit/s; a rate above it is not a valid setting on a classic CAN bus.
The fix
Put the machine around the controller in a safe state before you start: Reset (Original) restarts the controller and clears the state your session created.
- Run Reset (Original) from the IDE. It returns the controller's communication state to the factory default of 250 kbit/s, and the login works again.
- Set the IDE communication rate to 250 kbit/s, log in, and download. Confirm the download completes at the default before anything else.
- Run the application, then set the IDE rate to 500 kbit/s. The order is the whole fix: the change comes after a successful login made at the known default, never before it.
- When you finish, log out, close the visualization, set the IDE back to 250 kbit/s, and close the IDE. The reproduction of this fault kept the visualization attached across the close, so closing it removes the one open question in the sequence.
- If the crash comes back, run the same Reset (Original) again. For a permanent answer, send the controller maker the exact reproduction: reset, download at the default, switch to 500 kbit/s, log out with the controller powered, close the IDE, reopen, attempt the download.
Recommendation: recover with Reset (Original) whenever a download closes the IDE after a reopen, work at 500 kbit/s only after a login made at the 250 kbit/s default, and return the IDE to that default before closing; if the controller maker documents a permanent fix, take it and retire the manual sequence.
Worked example: 250 kbit/s IDE against a controller running 500 kbit/s
Inputs. The IDE session starts at its 250 kbit/s default, the value a reopened session opens with. The controller's channel runs at 500 kbit/s, the rate the application sets, and the application's one J1939 message per second is written for it.
The rule. A CAN node's bit time is the reciprocal of its bit rate, and two nodes exchange frames only when both bits last the same time.
The arithmetic.
- IDE at 250 kbit/s: 1 ÷ 250,000 bit/s = 0.000004 s = 4 µs per bit.
- Controller at 500 kbit/s: 1 ÷ 500,000 bit/s = 0.000002 s = 2 µs per bit.
- Ratio: 500 ÷ 250 = 2. The bus finishes every bit in half the time the IDE allows for it.
The result. Every frame the IDE listens to fails the bit and framing checks, the login never completes, and the failed download attempt closes the IDE.
The decision. Any difference between the two rates breaks the link, and a factor of 2 is a wide one. When a login fails right after an IDE restart with the controller still powered, compare the two rates before you rebuild anything: put the IDE on the application's rate after login, or recover with Reset (Original) and start from the default.
A mismatch that only logs you out
The crash belongs to this pairing. The same wrong rate on a serial programming link ends the ordinary way: the IDE reports a communication error, on some setups the one that reads Communication Error (#0), and logs you out with the IDE still open. Set both ends to the controller's documented value and the login completes. The values you meet on those links run from 9600 baud at the slow end to 57600 baud at the fast end; the link itself is covered in set up a serial port for CODESYS on Linux.
Other networks raise the same mismatch one level up. A PROFINET IP change not enabled error is the address version of it. And when the tool cannot reach the runtime at all after a configuration file edit, that is a different problem with its own fix: a CODESYSControl.cfg edit that locked you out.
Keep it from coming back
- Change the IDE rate only after a successful login at the default, never as the first move against a failed login.
- Return the IDE to 250 kbit/s and log out before you close, so the next session starts from the state the recovery expects.
- Close the visualization with the session. Leave it out of the sequence and the next session's starting conditions are fully known.
- Keep one rate change per session, in one direction, with the default on both ends at start and finish. If a download crashes anyway, Reset (Original) is still the recovery.
Questions
What does Reset (Original) do to the project on the controller?
Reset (Original) returns the controller's communication state to the factory default of 250 kbit/s, which is why the login works again afterwards. What else it clears depends on the controller, so keep the current project safe on your PC. After the reset you set the IDE to the same 250 kbit/s default, log in, and download the project again; that is the sequence that recovers this case.
Can a CAN bus run 250 and 500 kbit/s at the same time?
No. Every node on a CAN bus must use the same bit rate. A node set for 250 kbit/s divides time into 4 µs bits while traffic at 500 kbit/s runs in 2 µs bits, so no frame passes the checks in either direction. Choose one rate for the whole bus; classic CAN tops out at 1 Mbit/s.
Does the same rate mismatch happen on serial links?
It does, with a gentler result: a serial rate mismatch ends as a communication error and a logout, not a crash. Both ends hold a rate, the controller's manual lists its default, and the common values you meet run from 9600 to 57600 baud. Set both ends to the controller's value and the login completes.
Do I need to change anything in my application?
No. The project, its channel configuration at 500 kbit/s, and the J1939 traffic are correct as written. Everything that changes lives in the IDE session: when you set the rate, and what you leave it at before closing. Keep the controller's documentation at hand for its reset levels and its default communication parameters; both are named there.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.