Sideway

Hi, You can't update your MI 697 value since it's rewritten as the output of the linearization function. That's why the value of MI 697 would not change after entering a new value for it on the HMI. Sincerely yours, Sideway.

Hi kratmel, Thank you for your fast response ! Having a look at the example, i have been able to confirm that i configured it right on the PLC side. However i realized my slave device was not configured to handle NMT node guard (100Ch and 100Dh objects). By modifying them, i have been able to retrieve NMT Status on the PLC and the NMT toggle bit is working just fine. One last question about the Visilogic software in itself : How come the communication trial is RED with the CANbus test tool, yet i can communicate with my slave device correctly ? Have a nice evening, Cheers, Sideway.

Hi all, I have been investigating on NMT commands and how to deal with them in my CANopen project. I have created a project in which i bootup my PLC, then I send NMT Reset and Preoperationnal commands to my VFD drive (node 1). Once i am in Preoperational state, i can use my SDO commands. SDO commands are working fine. I can even ask for a NMT Stop command to disable them, then switch back to NMT Start. Problem is : i don't follow what's going on with the NMT commands. I would like to retrieve the NMT current status, but nothing is refreshed in my MI 2004 variable as shown below... Here is my function NMT Nodeguard, activating every second : May you help me solving this problem ? Sincerely yours, Sideway.

Hi everyone, I wonder if it there is any option or tool available to import/export communication addressing on Visilogic. I am currently using canopen and i would like to avoid entering the configuration of each and every node by hand (EMCY, NMT, PDOs bits and register addresses). I have 16 nodes to fill and i'd rather avoid any typing mistake. I think those addresses are hidden into Vision internal memory mapping but i wonder if there is any access to it other than entering each MB/MI by hand. Cheers, Sideway.

Hello ! Thank you for your kind reply ! I will work on it and try to make it even better One thing though : i am currently working on the big project (which includes the small train routine, that i left as is : i didnt change anything in it yet). This program is a lot more complex, and i really struggle architecturing it properly, especially with the I/O module which is mostly setting pneumatic actuators (that can be set/reset for a long period of time, thus i find it hard to use anything else than Set or Reset coils). The problem is : i have a lot of inputs (XB 1xx) and outputs (XB 2xx) from a WAGO external I/O module, CANopen communication with a servoDrive, HMI menus and navigation etc. I used "kind of" state machines for each region of my program (ie. i have like 5 subroutines for the Automatic mode only !), but unfortunately it's a real mess to manipulate, update and debug. Do you have any insight on how i could deal with such a big project or any architecture plan i could follow for really complex projects (in general) ? Cheers, Sideway. P.S. : Though the program isnt written in English, the idea here is to talk about the architecture of the program. No need to really understand what it's doing, only knowing which pieces it is made of is sufficient, i guess... CE prog v2.4 2022-05-20 .vlp

Hi, Thank you for your replies. I tried to adjust my program (quickly though), to understand the essence of state machine. Since i did slight adjustments, i did not manage to have one coil per state machine step (since some steps do not interact with my outputs at all). Also, consider XB100 - 199 to be my external inputs (sensors) and XB200 - 299 to be my external outputs (i am using CAN open so i retrieve these bits in a structure, not shown in that small program) I would like to practice on this small program to make it as clean as possible, to use it as a reference for future projects. Cheers, Sideway. train project v2.vlp

Hi everyone, I am currently working on a small project, in which i am automating the movement of a small "train" of boxes that i am filling with stuff. The train has two commands (move forward / backward) and three sensors (homing_position, box_is_full, box_detection). I control my train with three modes : Homing, Auto and Manual. My problem is the following : In order to move my train, i need to call the commands forward/backward multiple times in my routine in several rungs. I already know i can't use multiple direct coils because only the last direct coil state remains. On the other hand, if i write my code with a lot of set/reset coils, it becomes a bit hard to read. Do you have any suggestion or trick on how i could turn my code so that it remains readable without using set/reset coils ? I wrote TWO versions of my code : -> "train project.vlp" which i know is WRONG, but it is written with direct coils to illustrate how i would like the rendering of my ladder to be. -> "train project with set reset.vlp", which, i hope, is performing well although readability is worse. Cheers, Sideway. PS : I presented here a small project, but i have also been working on bigger projects, with, say 8 or 16 outputs all working together. And you can lose yourself easily with all the set/reset coils invading the project. train project with set reset coils.vlp train project.vlp

Hi everyone, thank you for your replies. The whole story is that i created a small program, split in two subroutines... And the goal was to send new XYZ coordinates to my drives after the last point had been reached. The purpose of my XB was : XB rises = load my position buffer into the drive and wait for the motors to reach target". When target reached, XB would reset and i would load new coordinates in my position buffer. Then i ask for XB SET again to load buffer into drive. Everything was working fine for the 1st point launched in the drive, but the program was blocking abruptly when asking for the 2nd point to be sent. And this was due to the weird rising edge failure i just shown. Cheers, Sideway.

Hello Isakovic ! At first sight, the program "should" work as you said (this is what i thought as well) ! I mean, i created this easy routine just to demonstrate the issue i had. And the issue, as you said again, is about how transition contacts are perceived from one scan cycle to another. I added some SB press keys just to be able to simulate my issue manually, when running in DEBUG mode, one scan at a time. When you do this, you may realize that the routine is working effectively only ONCE. When i go through another loop (i.e. when my MI goes back to 0 and XB resets), if i press "8" then the value 1 loads into MI but the XB rising edge is not seen and the program blocks.

Hi everyone, For sake of clarity, i decided to update this post, in a more compendious way, with a much simpler routine, going straight to the point. I have summarized the problem within the subroutine attached to this post (version used : VisiLogic 9.4.0) To describe it briefly : This routines executes well the first time i go through it. However, if i go Scan by Scan (using the OnLine debug mode), a problem occurs when i loop through my routine twice : XB23 (which is effectively 'Reset' at the end of the subroutine), does turn ON if i press #8 on my PLC, but XB23 Rising edge does not occur. However, if i go through my routine, reset my XB23 at the end of it, then i wait 1 scan cycle, then retry my routine, it works properly. May you explain what is going on ? Cheers, Sideway. TEST ROUTINE.vlp

kratmel, XB17 is a bit which sets ON when my CANopen configuration has terminated successfully ==> Once i configured my PDOs properly, i turn on XB17 to initiate a PDO Clock every 20 ms (which is later called to send RPDOs to my motor drives as shown below) EDIT : Discard XB1 direct coil, it is useless, just forgot to delete that one Ausman, i forgot that feature was actually available I was used to checking for the timer running within the timer variable list. I take good note of this one Thank you for your kind replies ! I have read the Timer help more in depth than i used to, and i understand it a bit better now Cheers, Sideway.

Oh ! Ok i think i got it : Since i dont use any rising edge when my coil goes ON, my TE33 stays on for more than one scan ? That's why my MI is counting down scan cycles, is that correct ? Cheers

Hi, I have tested again my program this morning and here is what resulted from my tests : 1) After downloading the program properly, and switching on/off my machine, i found that my TE33 timer was working, since my MI was incrementing, as shown below : As you said, TE33 is not showing that it's powered up within Visilogic (neither in the ladder section, nor in the timer array) 2) I have tried again without SB1, and the result was exactly the same. 3) I have tried with a slower timer value for TE33, and the result was quite interesting : As you can see, i set up MI to equal 0 on power-up. The MI variable attached to TE33 is incrementing a lot faster than TE2, eventhough my TE33 is slower. And yes, i downloaded the program (download + reset), then restarted my machine just to be sure. Any idea on what's going on here ? Cheers, Sideway.

Hi ! I have read your answers carefully, and will retry tomorrow morning so that i can give you a feedback As you said, maybe I forgot powering up again the machine after downloading... which may sound stupid buuuuuut it may not be the first time for me However, i am SURE about this : the two timers TE2 and TE33 were never used anywhere else. I just called them for the demo ! (So, no double direct coil, reset coil forgotten or anything of the sort...) And the lungs are in the Main Routine, just to be sure i call the routine properly Oh and Ausman... what is WAN ? Never heard about this Cheers, Sideway.

Hi Flex, I have often been manipulating timers for CAN communication and they are all in milliseconds *10 (we need our devices to answer fast ). And usually, if my timers are working, i can see them blinking (switching on and off) within Visilogic. I checked for my timer TE33 here, and it does not turn ON, even with a MI increment next to it. Cheers, Sideway.