1 is a number, only TRUE and FALSE are allowed to be assigned to a BIT.
An invalid pointer (either because it is 0 or points outside the memory reserved to the program) is being dereferenced. Track down pointers or interfaces that you have in code and check them - you should also be wary of mixing online change and pointers.
Did you deactivate the debug console via Daemon->HMD subdevice? See the attached picture. Otherwise the port is already seized by the Linux system. You'll need to reboot the display via ignition (not via power supply) for this setting to take effect.
Anyway a better way for what you want to achieve is executing the task with 32 ms (or submultiple like 16, 8, 4 ms...) execution time and increment the counter every 1 (2, 4, 8...) cycles without timers. You'll get the best behaviour your platform can provide.
First - what's the task cycle time? Timers cannot have better resolution than that. E.g. if your task cycle time is 20 ms, the following happens (every bullet is a cycle - the first is the global clock): 1) t#000ms - IN = TRUE - ET = t#0ms - Q = FALSE 2) t#020ms - IN = TRUE - ET = t#20ms - Q = FALSE 3) t#040ms - IN = TRUE - ET = t#40ms - Q = TRUE 4) t#060ms - IN = FALSE - ET = t#0ms - Q = FALSE 5) t#080ms - IN = TRUE - ET = t#0ms - Q = FALSE 6) t#100ms - IN = TRUE - ET = t#20ms - Q = FALSE 7) t#120ms...
There is no way to make ETrigTo variables xExecute/xDone/xError/xBusy alongside ClientRequest own ones (see attached picture). One can have them only by calling the block as CBML.ETrigTo but then specific ones are lost. In CFC, on the other hand, they all show up fine. Furthermore, IClientRequest interface seems to be hidden.
It's probably done in the hardware. You should ask the manufacturer, typically the peripherals that do that stuff already have both the high/low time and the period information.
Quoting the documentation at https://content.helpme-codesys.com/en/CODESYS%20Visualization/_visu_dlg_project_settings.html You can also configure a visualization element with a property in those properties where you select an IEC variable. Then CODESYS creates **additional code** for the property handling when a visualization is compiled. So I guess that not using properties, thus not generating additional code that's executed every time the element is rendered, should be faster than using them....
We have some slaves mastered by a Topcon panel. CAN communication works, PDO exchange continues to work correctly, whereas SDO writes crashes: SDO_READ4 is called correctly and timeouts correctly, however no corresponding SDO request is ever made on CAN bus.
I had the same problem just today with coUnit v1.2.0.0. Library parameters are not editable so I cannot increment the related array size.
Have you tried to look into "Asignacion E/S" (I/O Mapping in English)? You should check in the parent device as well. You should have the possibility to map individual bits of the UDINT to BOOL variables. Check the documentation of your drive for correspondence between bits and outputs.
Have you tried to look into "Asignacion E/S" (I/O Mapping in English)? You should have the possibility to map individual bits of the UDINT to BOOL variables. Check the documentation of your drive for correspondence between bits and outputs.
In general you cannot return a different data type except with a union. If you want stronger typechecking, you could return a pointer to the data (in pointer to byte) and a reference to a "decoding interface" that inherits from a base one with no .Decode method, and then you dispatch via __QUERYINTERFACE.
They should be in seconds.
Utils.PID provides bumpless transfer, however one could also look into Control Loop Library (awesome BTW).
You can use the "Relative movement properties" of the rectangle: https://content.helpme-codesys.com/en/CODESYS%20Visualization/_visu_elem_rectangle.html#UUID-09c53adc-3a90-3f8d-f30d-689f581b7c5f
If you have synchronization enabled, you NEED realtime behaviour thus you need RTE runtime. Otherwise synchronization does not work and errors out.
https://stackoverflow.com/questions/11927848/ewouldblock-error-in-socket-programming It means that the call would block if the socket was blocking, but it does not because it is non-blocking. It basically means "I cannot read/write anything, since you do not want me to block until I can, just retry later".
0C000003 is 4 bytes, high to low: 0C 00 00 03. So you do 03 + 00 + 00 + 0C + byte[0] + byte[1] + byte[2] + byte[3] + byte[4] + byte[5] + byte[6]
No manual. This is the manual for developing libraries https://content.helpme-codesys.com/en/LibDevSummary/index.html but it's only tangentially related. If you are able to use the Codesys Library Manager (documented at https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_obj_library_manager.html ), then locate the OSCAT NETWORK library (should be in C:\ProgramData\CODESYS\Managed Libraries\OSCAT\NETWORK\1.3.5.2), save in another location and open it, increase the library version...
No manual. This is the manual for developing libraries https://content.helpme-codesys.com/en/LibDevSummary/index.html but it's only tangentially related. If you are able to use the Codesys Library Manager (documented at https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_obj_library_manager.html ), then locate the OSCAT NETWORK library (should be somewhere C:\ProgramData\CODESYS), save in another location and open it, increase the library version under "Project Information",...
Sorry, did not read that you are using OSCAT NETWORK. You are unfortunately out of luck, but IIRC OSCAT libraries are installed in source form, so you can change the dependencies to SysFile and SysSocket2 and the relevant calls inside the library, then recompile. These two compatibility libraries won't be adapted to run on 64-bit.
Why are you using the compatibility libraries (same interface as the Codesys 2.3 one)? There's no chance these libraries will ever work on a 64-bit processor like the CR1203 one. They are not maintained anymore. Use SysFile and SysSocket2 instead and adapt the relevant calls.
Are you really sure? What types are a and b in your example?
https://unix.stackexchange.com/questions/174349/what-overwrites-etc-resolv-conf-on-every-boot https://unix.stackexchange.com/questions/483619/resolv-conf-overwritten-every-time https://stackoverflow.com/questions/15368217/how-to-prevent-etc-resolv-conf-from-getting-overwritten-after-reboot-in-ubuntu
Are you sure that it's Codesys and not some daemon like dhcpcd or NetworkManager?
Have you looked into Util.PACK? https://help.codesys.com/webapp/dcArNB9jo1tNw8mpfoJaDnLo8No%2FPACK;product=Util;version=3.5.17.0
Perhaps you can find it in OSCAT, not in the standard libraries. Anyway... FUNCTION_BLOCK InputChangeMonitor_WORD VAR_INPUT i_Value : WORD; END_VAR VAR_OUTPUT o_Changed : BOOL; END_VAR VAR old_Value : WORD; END_VAR o_Changed := i_Value <> old_Value; old_Value := i_Value; And with threshold FUNCTION_BLOCK InputChangeMonitorThresholded_WORD VAR_INPUT i_Value : WORD; i_Threshold : WORD; END_VAR VAR_OUTPUT o_Changed : BOOL; END_VAR VAR old_Value : WORD; END_VAR IF i_Value > old_Value THEN o_Changed :=...
Perhaps you can find it in OSCAT, not in the standard libraries. Anyway... FUNCTION_BLOCK InputChangeMonitor_WORD VAR_INPUT i_Value : WORD; END_VAR VAR_OUTPUT o_Changed : BOOL; END_VAR VAR old_Value : WORD; END_VAR o_Changed := i_Value <> old_Value; i_Value := old_Value; And with threshold FUNCTION_BLOCK InputChangeMonitorThresholded_WORD VAR_INPUT i_Value : WORD; i_Threshold : WORD; END_VAR VAR_OUTPUT o_Changed : BOOL; END_VAR VAR old_Value : WORD; END_VAR IF i_Value > old_Value THEN o_Changed :=...
Well, first you should check which task is used as bus cycle task. Double click the related CANL2ConfigX, go to the "CANL2ConfigX I/O Mapping" tab and check which task is used (figure 1). If "Use parent bus cycle settings", then double click the main device (the parent of the PLC logic node), then go to "PLC settings tab" and examine which task is selected in "Bus cycle options" (figure 2). If that is "<unspecified>" then it's the cyclic task with the shorter interval in your task configuration.</unspecified>...
The ReceiveMessage holds only the latest received message during the bus cycle. Solutions: - reduce the cycle interval of the bus task associated to ReceiveMessage to be less than the message interval, and process messages in that task - receive the messages via CL2 - if you are using a multipacket protocol for transport, consider switching to CANopen or J1939 The last point does not work for multiplexed messages, where a field marks the content of the messages. Topcon Projektor has native support...
The ReceiveMessage holds only the latest received message during the bus cycle. Solutions: reduce the cycle interval of the bus task associated to ReceiveMessage to be less than the message interval, and process messages in that task receive the messages via CL2 * if you are using a multipacket protocol for transport, consider switching to CANopen or J1939 The last point does not work for multiplexed messages, where a field marks the content of the messages. Topcon Projektor has native support for...
First, what target are you using (because SP17 has not been released yet for Opus panels)? What bitrate are you currently using, and what is the task cycle time associated with message processing? At 250 kbit/s, at most 22 messages can be transmitted every 10 ms (100% busload), so making a buffer hold (say) 500 messages would not solve your problem. How are you receiving messages, via CL2 functions, via CANopen/J1939 managers or via Topcon special subdevices (TransmitMessage/ReceiveMessage)? Could...
Well, please explain what values you want O1 and O2 to assume at each point of the following sequences (all starting from not pressed / scratch): 1. <r1,r2,r3>,P1, P2, R2, R1 2. <r1,r2,r3>,P3, R3, P3, R3 3. <r1,r2,r3>,P3, R3, P1, R1 4. <r1,r2,r3>,P1, R1, P3, R3 5. <r1,r2,r3>,P1, P3, R3, R1, P3, R3, P1, R1 6. <r1,r2,r3>,P1, P3, R1, P1, R3, R1</r1,r2,r3></r1,r2,r3></r1,r2,r3></r1,r2,r3></r1,r2,r3></r1,r2,r3> I guess some, based on your post: 1. <o1f-o2f>,O1T-O2F, O1T-O2T, O1T-O2F, O1F-O2F 2. <o1f-o2f>,O1T-O2F,...
Well, you can use the built-in stuff to read from a serial port (see my previous message) or you can continue to abuse SysProcess* functions to do the same in a more fragile and inconvenient manner via Linux commands. If your smartmeter sends bytes that have value 0, the string functions will assume that as the end of the string, whereas the serial port functions will happily continue to work correctly. It's up to you to shoot yourself in the foot like you are doing. StringUtils are for working with...
The first error message asks you to compare the runtime you defined in the project (you can see it double clicking on the main device and then Information or something like that) and the runtime that is running on the BeagleBone (that you can find when you scan the network). After they're equal up to the first 3 numbers (es 3.5.17.xx), and the fourth is closest, then you can start chasing the second if it still is there. These functions are available only from runtime SP18 (CmpCrypto version 2.0...
You should look into SysCom or CAA SerialCom libraries, since it appears as a (virtual) serial port.
You need to provide a variable (from the name I think an array of BOOLs) to the FB, that the block can then read or write. You pass it like you pass a VAR_INPUT, except the FB can change it.
That unfortunately requires hooking up a PC. 5 minutes vs 30 seconds, multiply that by 10 machines/day and the difference is 5 minutes vs 50, or 10% of a working day... Activation at first connection (e.g. on the portal you see a "Hi I'm there" from the not-yet-registered machine and then activate it via some clicks) would be better.
Is there a way to deploy Edge Gateway configuration (URL/certificate) without connecting with the IDE and manually configure the server and the rest? Currently the application is loaded at end of line with an USB key, hooking up a PC and manually configure the unit for each machine would be a PITA...
Sorry, I forgot to say that the resolution was much more mundane. The loopback interface on Topcon devices is off by default. Both the running gateway AND the edge gateway can run in parallel without interference if it is enabled. Anyway, they plan to integrate the CmpEdgeGateway component in the next releases of the runtime, so the problem would solve by itself ;-)
Any SocketCAN-supported device should work well. Peak, Kvaser, Vector...
Also on Automation Server web page the Edge Gateway on A8 reports itself running on port 1217 instead of 11217 (verified with netstat, it would fail the bind otherwise).
I have a Topcon A8 in which I manually installed the Edge Gateway 4.0.1.0 (because of SP16) from .deb file (since it does not have dpkg). It is configured to bind on ports 11217 and 11741 (because the default gateway already binds on 1217 and 11743). The Edge Gateway connects successfully on Automation Server, but one cannot see the actual PLC runtime listed after a scan. stracing it shows EADDRNOTAVAIL in binding on 127.0.0.1:4965 and 127.0.0.1:4966, reflected on messages "CommDrvTCP: 'Bind' failed...
Well, that's how a PID works. The integral action charges up in order to sustain the PV value: when the error is zero, derivative and proportional action are zero, and the only thing that keeps the process value from going back to its equilibrium is the integral action.
You can build a list of pointers (or interfaces, if you use function blocks), and then batch process it. VAR CONSTANT settingsNumber : UINT := 4; END_VAR VAR apSettings : ARRAY [1..settingsNumber] OF dut_Settings; i : __XWORD; xDoTask : BOOL; axDoTask : ARRAY [1..settingsNumber]; (* For option #2 *) END_VAR (* Initialization, somewhere *) apSettings[0] := ADR(PVL.dut_PonyGroupSettings); apSettings[1] := ADR(PVL.dut_MidGroupSettings); apSettings[2] := ADR(PVL.dut_MainGroupSettings); apSettings[3]...
I have a rather strange issue with SP16 patch 5. If I have all visualizations and their backing logic under POUs, the compiler warns about VisuDialogs.NumPad missing from Visualization Manager (even if it is checked there), and trying to download program anyway causes an exception to be thrown in VISU_TASK (Codesys says it's somewhere in Trace Manager library, but from my experience that indication is not always reliable). That was after the first download, when compiler did not complain but I soon...
What's the "Codesys Control for Raspberry PI" version in the device tree? What's the "Codesys Control for Raspberry PI" version running on the PI? What's your Codesys IDE version? Hint: the first two should match, at least for the first three numbers (eg. 3.5.16.10 and 3.5.16.20).
Thank you. I was sure I was forgetting something trivial π Last time I had multiple applications in the same project was 2019...
I have two display variant that share most of POUs. According to the documentation, "The POUs view includes objects that can be used throughout the project. Programming objects that are intended for a specific application must be inserted below the application object in the Devices view (device tree)." So I thought "Good, let's put PRGs with the same name but slightly different behaviours under different devices", but it seems that Codesys links (highlights in blue) only one of the couple, even though...
Yes. You'll suffer for multiple END_IFs in the second case.
Hi Marcel, here you are. Sorry for the delay. You'll have to adjust LoadNames.defaultfilename and LoadNames.outputfilename according to your system. I attached the custom "mytl" in the projectarchive. If you set a breakpoint into LoadNames.LoadCustomFile, you'll see that resUnreg is 1 (generic fail). To keep it short, I did not implement the logic which asks for default text if LoadNames.xCustom is true, because if unregistering fails it won't work anyway.
You defined a function "Pack_16" and then proceed to call "Pack_16" inside it. How do you think this can work? Apart that recursion is generally disallowed (as opposed to other languages), but this would not make sense either, since you are not going to reach a base case. If you try this e.g. in C your program would hang indefinitely or get terminated by the OS due to a segmentation fault. Furthermore, I really doubt you can shove 16 bits in a BYTE...
I'll look into it. Thanks.
Home, End, Esc, Tab, Up, Down, Enter. How would you do it? For the time being I had to redirect every call to a global memory area, but I am still interested in making this work the "right" way.
I was not referring to the Codesys IDE, but to the TargetVisu runtime. The problem is that a display key is mapped as "Tab", another as "Up" and so on. This is at the OS level (Linux embedded), fixed. So if I activate "Standard keyboard handling" and I press the key that generates a "Tab" keypress, it moves focus {instead of}/{in addition to} doing the action associated with that key in the code. Same for Up, Down, Home, End and so on. These keycodes have no special meaning attached, the manufacturer...
Yes. But these action could be intertwined with touch actions. I tried the stock selection example, but it "worked" only if I activated the "Standard keyboard handling" (and it did not work at 100%). Unfortunately the display own keys (some are mapped to the arrows, some to Tab, some to Enter and so on) cease to work correctly, because the keypresses are interpreted by Codesys instead of just being forwarded to the visualization (that already handles them).
The keyboard must be controllable both by touchscreen and by CAN keypad (similar to the Grayhill one, with a wheel and some keys). On some machine models the display does not have the touchscreen, so IEC control is the only way, on other models the user could open the keyboard from CAN but then proceed to write by touchscreen and then confirm/cancel via CAN (or via touch). So the "presses" can be intermixed from touch and CAN (thus there is an event queue which guarantees serialization, even if the...
Here you are. It is a "work in progress" and needs a LOT of polishing (from supporting multiple keypads to a general reorganization). In the PLC_PRG there is a small test/explorative project where you have variables for simulating a push, rolling around and opening the window from IEC code (or not).
I am trying to make a on-screen keyboard which can be commanded both from touchscreen and IEC code (external, remote input). I am on Codesys SP16 because of target. So I copied VisuDialogs and added a visualization and a manager to handle IEC-side events. I found, via Visu Dialog ST example, that an IVisualizationDialog.GetDialogInterface method exists, and it seems to work by temporarily changing visualization own IVisualizationDialog._pInterface (because when halt on breakpoint I see the referenced...
Yes, we know... we sell both Epec and Topcon :-) There are 4 (main) partitions on the display, the OS, the Service OS, the Shadow Update and the Application (which includes the runtime). Interesting, IIRC on EGScore series the OS partition is normally mounted read only (it's the rootfs_egscore_xxx.tar.gz, for the reference) so that /root is normally not writable.
Well, the main problem is "I don't really understand how to build this", especially because you are a student (but even if you were a technician, you are supposed to understand how to do a simple task like this). For SFC, just read the documentation: in the help there is a entire section titled "Programming of applications" https://help.codesys.com/webapp/_cds_struct_application_programming;product=codesys;version=3.5.16.0, then there are countless tutorials and examples (in the guide there is also...
https://en.m.wikipedia.org/wiki/Sparse_voxel_octree https://en.m.wikipedia.org/wiki/K-d_tree https://en.m.wikipedia.org/wiki/Point_cloud https://duckduckgo.com/?t=ffsb&q=point+cloud+data+structures&ia=web https://stackoverflow.com/questions/29145859/advice-on-data-structure-for-point-clouds You NEVER convert it into a full-blown 3D matrix. If you are only doing a touch-probe scan, you could get away with a linear array or even with a "last point", i.e. 6 coordinates, and move by delta (maybe checking...
So I guessed correctly that you were trying to build a point cloud (and that's where the "at least 99.99% will always be FALSE" came from ;-) ) and that's exactly the reason why they're always stored in a sparse matrix (that could range from a simple linear array storing coordinates to more complex data structures).
The Codesys help reference this library in "Synchronization of Concurrent Execution" page https://help.codesys.com/webapp/synchronization;product=LibDevSummary;version=3.5.17.0 talking about message queues vs. shared memory. Since I was investigating that page to build a N-producer,1-consumer message queue synchronized by SEMA (doh!), I thought "Fantastic, infrastructure has already been created!" but then I stumped into the documentation... er, not: I could not stump into it because there was NO...
https://help.codesys.com/webapp/_cds_pragma_attribute_pack_mode;product=codesys;version=3.5.16.0 1-byte variables are always packed at byte addresses irrespective of the pack mode. You can verify experimentally for yourself (I did it on x86, x86_64, ARM Cortex-A and PowerPC e200z7).
A BOOL is stored as 1 byte, 8 BOOLs are stored in 1 64-bit word or 2 32-bit word. But even if you pack 8 BOOLs/byte you have 1,4 GB of data for each array. And this is a giant code smell for PLC code. That's why the default size is 4 kB (almost always you need less than 1 kB), not including visualization which gets a separate area. If I guessed correctly your target application, at least 99.99% of these BOOLs will always be FALSE. Perhaps you should look into sparse matrices representation? Anyway,...
For general reference, "Implement Interfaces" does not work ("No methods found") because interface is hidden. However, there is a workaround: 1. declare a FB implementing the interface you want. We'll call it FBI. 2. declare in a scratch POU a variable of the hidden interface you want to implement. We'll call it "itf" 3. then write in the implementation of the POU "itf." and then invoke autocomplete (CTRL+Space); a list of methods will appear. 4. for each method shown (one could also autocomplete...
Well, if you correctly reinstalled the runtime, it comes back to 192.168.0.2. Perhaps you actually did not reinstall the runtime correctly (you should start from disconnected supply and connect supply, ignition and SERV_EN together), then insert the USB pen and check the installation log. When you reinstall the runtime, the entire partition holding everything other than the OS (so runtime, application, stored data and so on) is erased (obviously you should install only the runtime, user_ and user3_...
Ok. The application can definitely be installed along with the OS if you follow the instructions in "Creating USB Memory for Updating Application (6505)" page of the manual (you obtain a user4_*.tar.gz file along with its checksum). To reset to factory conditions (so removing user management), you should update the runtime, placing ONLY user_* and user3_* files in the USB drive, connecting it to the 6505 (that should be disconnected from supply) and then booting with SERV_EN connected to supply....
Ok. The application can definitely be installed along with the OS if you follow the instructions in "Creating USB Memory for Updating Application (6505)" page of the manual (you obtain a ~~~user4_*.tar.gz~~~ file along with its checksum). To reset to factory conditions (so removing user management), you should update the runtime, placing ONLY ~~~user_~~~ and ~~~user3_~~~ files in the USB drive, connecting it to the 6505 (that should be disconnected from supply) and then booting with SERV_EN connected...
Ok. The application can definitely be installed along with the OS if you follow the instructions in "Creating USB Memory for Updating Application (6505)" page of the manual (you obtain a user4_*.tar.gz file along with its checksum). To reset to factory conditions (so removing user management), you should update the runtime, placing ONLY user_ and user3_ files in the USB drive, connecting it to the 6505 (that should be disconnected from supply) and then booting with SERV_EN connected to supply. If...
Could you please detail better what do you want to do? Exactly, what do you mean by "boot drive"? The firmware packet, the application packet installable from service OS or the application packet installable by the ApplicationLoader? Are you talking about the Codesys credentials to log onto 6505? BTW, you'd better use Linux (a VM is enough) to make SW packets for 6505.
Well, it depends on your device. If you click Online -> Create Boot Application, you'll get an Application.app file and a Application.crc file. Then follow the instruction for your device.
You can change the Source Address of a J1939 Local ECU calling method ChangeAddress on it.
Create an image with the color wheel. Handle mouse events with respect to the point of the color wheel pressed. See example project for how to implement event handlers https://forge.codesys.com/prj/codesys-example/visu-event-hand/home/Home/ Compute the color starting from the coordinates after transforming them as angle/distance from center. Set the color and move elements accordingly (via absolute movement properties).
Create an image with the color wheel. Handle mouse events with respect to the point of the color wheel pressed. See example project for how to implement event handlers https://forge.codesys.com/prj/codesys-example/visu-event-hand/home/Home/ Compute the color starting from the coordinates after transforming them as angle/distance from center.
If it is not possible to understand why unregistering the default file fails, I think it's better to go the build-from-scratch way...
I cannot seem to be able to change default texts. They are NOT changed from the default file even if I unregister it. But texts with IDs not present in the default file are imported successfully. "outputfilename" is '/opt/data/mytl.txt' It has only "Id;Default" instead of "Id;Default;it;en;de" columns. LoadCustomFile (does not overrides default texts) // Current language save/restore because on text reload the language reverts to "" // Even without it, so in the "" CURRENTLANGUAGE case, default texts...
I cannot seem to be able to change default texts. They are NOT changed from the default file even if I unregister it. But texts with IDs not present in the default file are imported successfully. "outputfilename" is '/opt/data/mytl.txt' It has only "Id;Default" instead of "Id;Default;it;en;de" columns. LoadCustomFile (does not overrides default texts) // Current language save/restore because on text reload the language reverts to "" // Even without it, so in the "" CURRENTLANGUAGE case, default texts...
If I'd were in your footsteps, I'd implemented a socket interface instead of a shared memory one.
Please detail how you connect desiredDutyB02 to the hardware channel ("Outputs I/O mapping" pane), if the PWM output is enabled and if the controller reports any diagnostic such as "Open circuit", "Short circuit" and so on. This controller seems to have a master relay switch (that cuts outputs supply off), have you enabled it?
Sorry, I messed up with the import file (not the globaltextlist.txt), the one that has the textlist as the first column. I'd like to keep the original file if something goes wrong as a fallback solution, unregistering it if the other file is valid.
Yes, but what's the right format for the file? Is it the same as <textlistname>.txt or the one of globaltextlist.txt? Should I unregister the previous file or not?</textlistname>
I need to load at runtime a TextList, so I wandered around CmpDynamicText library and saw DynamicTextRegisterFile, DynamicTextUnregisterFile and so on. Is there an usage example somewhere, or at least someone who has make it work? Or should I replicate TextList infrastructure in IEC code instead, something like the following pseudocode? PROGRAM LoadTexts VAR_INPUT xExecute : BOOL; filename : STRING; END_VAR VAR_OUTPUT textList :ARRAY [0..255] OF WSTRING; END_VAR VAR i : UINT; _xExecute : BOOL; parsed...
I need to load at runtime a TextList, so I wandered around CmpDynamicText library and saw DynamicTextRegisterFile, DynamicTextUnregisterFile and so on. Is there an usage example somewhere, or at least someone who has make it work? Or should I replicate TextList infrastructure in IEC code instead, something like the following pseudocode? PROGRAM LoadTexts VAR_INPUT xExecute : BOOL; filename : STRING; END_VAR VAR_OUTPUT textList :ARRAY [0..255] OF WSTRING; END_VAR VAR i : UINT; _xExecute : BOOL; parsed...
You have two options. First, you can do the "safe way" with two FOR cycles (assuming Main.Length + 1 = (Main.Width + 1) * (Main.Groups + 1) based on how you declared the two arrays) FOR i := 0 TO Main.Width DO FOR j := 0 TO Main.Groups DO aDivided[i, j] := aWhole[i * (Main.Groups+1) + j]; END_FOR END_FOR Second, you can use CAA Memory Library functions like MEM.MemMove(pSource := ADR(aWhole[0]), pDestination := ADR(aDivided[0,0]), uiNumberOfBytes := Main.Length+1);
Try to add some "../", I guess that "../../../../Images/Keypad.png" will work ;-)
"CANopen Manager -> General -> NMT error behavior" is perhaps set to "Stop Slave"? Shame that there isn't a "Do nothing" option...
The 30 minutes are counted from the start of the runtime with the application using EtherCAT master, so just reboot ;-) Source: I did a trial back in 2019 for a licensed device which did not have EtherCAT license.
Have you tried asking IFM for support? Because it seems that the problematic libraries are hardware-related. Furthermore, this is the wrong sub (you should post under Engineering).
It is only a graphical thing that signals you that these signals are not part of a safety chain (because they're BOOL), but it will compile fine.
Bear in mind that I am not the OP, I do not want to implement an acknowledgement scheme in J1939. Some manufacturers of safety-certified J1939 devices use inverted signals on two different addresses and/or counter+CRC and monitor timeout of received messages if any, but I do not know anyone that check for an acknowledgement. The only request/reply pattern I implemented in a J1939 ECU was a CANopen SDO interface on Proprietary A.
No. The Codesys slider is a really poor made control... I always end up implement one with a line/rectangle for the background and a line/rectangle/image/... for the handle. If it is readonly it ends here, if you need to support input it's not so complicated (the downside it's you have to work in absolute coordinates in code behind).
Well, "intrinsically safe" and "cannot have any data losses" are big statements. First of all, a communication protocol is almost never "intrinsecally safe", let alone J1939. Perhaps the control units are, but not the protocol itself. By default, except on some PGN like TSC1 (if counter&checksum are not 0xFF anyway), you cannot detect e.g a "babbling idiot". You don't have by default transmission of bit-inverted signals along with straight ones like in CANopen safety or CRC like in STW custom safety...
Yes, in this case you can check a response with a ReceiveWatchdog https://help.codesys.com/webapp/LvXY4WjsWFNOt1Hf6flhwiAK3oY%2FReceiveWatchdog;product=IoDrvJ1939;version=3.5.17.0 and examining the content of your custom acknowledge message when xReceived output goes TRUE. But a Proprietary B is a broadcast message. There is no "receiver" as far as the J1939 standard is concerned. If you really want to have a "destination" you should use the Proprietary A (and implement acknowledgement, since it...
Just use a TON and compute timer.PT - timer.ET (that's the remaining time). And then hookup it into a pie element. Otherwise please specify the data you are operating on.
Er... what kind of messages are you transmitting? If you are transmitting a normal PGN (not the ones, mainly from J1939-73 or e.g. the Reset, that require the ACK/NACK response) you have no way to know if the remote control unit has received the message, because CAN is an unconfirmed protocol and most J1939 PGN are unconfirmed.
The focus is on the readability, almost everyone can roll a (de)serialization code. A library function which is already made and does everything right and aptly named is way better than something that would be copypasted all over the place and quickly gets messy. Besides that, your code is broken on 16-bit processors. Yes, they still exist, run Codesys and continue to be deployed.
This works only if you have a big endian machine. The easiest way would be using the dedicated functions from CAA Memory.